FEATURE REQUEST: set permissions on appdmg installer

[munki]

FEATURE REQUEST: set permissions on appdmg installer

[natewalck]

From [email protected] on July 21, 2010 13:18:36

I think this sort of thing would be better handled by repackaging the app. Then you can set any owners or permissions you want, and the behavior is the same whether munki installs it, or its manually installed.

Owner: [email protected]
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low

[natewalck]

From [email protected] on July 21, 2010 13:26:25

Yes, I have done this repackaging already with Firefox.
I guess I have to start building a command-line based build-train using Iceberg templates for any customised apps...

[natewalck]

From [email protected] on July 21, 2010 15:25:16

It would be useful, but not a great priority for me. If appdmg changes are made, the ability to target /Applications/Utilities as well would be helpful.

While repackaging will work, Munki philosophy is that we should be able to use the vendor supplied installer/dmg in as many case as possible.

Some specific use cases for allowing the permissions to be configured more permissively:

1. use of Munki on personally owned / student machines, where Munki will be removed once they leave the organisation. We want to do installs in a manner that will not prevent self-update features working later.
2. one-shot automated installs/updates - eg: if a computer repair shop wants to use it to get all the basics cleaned up / up-to-date then remove Munki (no continuing management of / root access to the computer).
3. simply choosing to allow Munki to co-exist with other update mechanisms. Allow the admin to choose to be lazy in how quickly they get certain updates out, but to allow vendor update mechanisms still to work. A Munki strength is that it is stateless and coexists with other update mechanisms and user installation actions.

(However, with added complexity being added to pkginfo files, makepkginfo may need to get smarter over time -- can I give it the pkginfo of the last version as well & have it merge the settings from the last version with new version information from the new version? Though I also have designs on the '-f' command being able to read Info.plist files from the pax archive directly rather than requiring an install)

[natewalck]

From [email protected] on July 21, 2010 15:51:39

"While repackaging will work, Munki philosophy is that we should be able to use the vendor supplied installer/dmg in as many case as possible."

And if the vendor-supplied dmg is a drag-n-drop disk image, the expectation is to just copy the files, not to do any post-copy owner/permissions jiggering. If you need that, then you are re-inventing the package format, IMHO.

munki doesn't apply any specific permissions; it just does a cp -R.

[natewalck]

From [email protected] on July 21, 2010 17:54:11

"munki doesn't apply any specific permissions; it just does a cp -R."

My mistake - I had false memory of reading a permissions change in that part of the code.

The outcome of the behavior is however still quite different to a user dragging & dropping -- in that case it is usually the main user of the machine dragging & dropping into Apps. Thus they are the owner, thus Firefox has permissions to self-update.

But perhaps a postflight functionality within the pkginfo would more flexibly serve the need? (that being: still be able to use the vendor 'package', but apply fixes post install).

[natewalck]

From [email protected] on July 21, 2010 22:49:10

"The outcome of the behavior is however still quite different to a user dragging & dropping..."

Yes, if a GUI user copies an app from dmg that user is the owner of that item, not root (like in the case of munki).
I did some testing and gave group read+write access on source .app, then copied it using cp -R from source to /Applications, running as GUI-user and as root. In both cases cp -R seems to set admin group read-only access, it is using the /Applications default permissions, at least with 10.6 and probably with 10.5 also.

"But perhaps a postflight functionality within the pkginfo would more flexibly serve the need? (that being: still be able to use the vendor 'package', but apply fixes post install)."

These special permissions (if existing) should be applied after the .app is copied (within the function executing the copy).

[natewalck]

From [email protected] on July 23, 2010 06:34:24

I have a patch available for adding this support if anyone is interested (see attached file). This patch applies cleanly against the latest SVN revision (600, IIRC).

The major change is that I added an 'installer_options' dictionary to the pkginfo; this dictionary is then passed as a second, optional argument to copyAppFromDMG when processing the install (see below for an example).

I also added '--owner','--group' and '--mode' options to 'makepkginfo'. The owner and group are passed directly to chown/chgrp so they may be numeric or symbolic but mode expects a symbolic argument (for example, 'u+w,g+wx,u-w'). If any single element is missing or the whole dictionary is missing/empty, munki will just follow its normal behavior. Any comments or suggestions are welcome!

Files Modified:
M code/client/makepkginfo
M code/client/munkilib/installer.py
M code/client/munkilib/updatecheck.py

Example 'installer_options' dictionary:
installer_options

group
admin
mode
u+w,g+w
user
root

[natewalck]

From [email protected] on July 23, 2010 08:19:42

guiyon - thanks for this. I intend to accept this patch, or a version thereof, but I have a few questions/comments.

1. In the patch for makepkginfo, def check_mode() contains this function:

• def uniq_str(str):

•    seen = set()
  

•    res = []
  

•    for item in str:
  

•        if not item in seen:
  

•            res.append(item)
  

•            seen.add(item)
  

•    return ''.join(res)
  

It doesn't appear to be used. Can it be removed? Or were you planning to use it and forgot?

2. In the same function, you check the modes against this regular expression: re.compile("(a|[ugo]+)[=+-][rstwxXugo]{1,9}"). In installer.py, in the patch for copyAppFromDMG(dmgpath), you use a different regex to sanitize the mode string. Can you talk about that a little more? I'm sure I just don't understand what's going on.

3. I think the key name should be something other than "installer_options". To me, that implies either it works for everything that munki knows how to install, or at least applies to those things installed using /usr/sbin/installer. "appdmg_options" is better, but if we add an install method that can copy an item from a disk image to any given path, the owner/group/mode stuff would be useful there. Any suggestions?

[natewalck]

From [email protected] on July 23, 2010 08:55:35

3. I think the key name should be something other than "installer_options".

How about naming it "item_permissions"?
And the level it is positioned within pkginfo tells munki how to apply permissions. If it is at top level then these permissions are applied to all defined destination items. If this array is found at item level then munki applies these permissions only for current item only. These item-level perms should have priority over general perms which are applied to other items without any specific item_permissions definitions.

[natewalck]

From [email protected] on July 23, 2010 09:18:50

I don't think there should be more than a single item copied and therefore a single set of owner/group/mode. If you need something more complex, make a package.

[natewalck]

From [email protected] on July 23, 2010 09:30:17

1. That was me being absent-minded! The line
   "mode if not value else (value + "," + mode)"
   should of been:
   mode if not value else (value + "," + uniq_str(mode))

The point of that function was simply to perform a sanity check on the mode so that repeated characters in the modestring would be stripped out (for example: ugu+rwwx => ug+rwx). After a bit of testing it seems that chmod is fairly resistant to those sort of errors so the method can just be removed.

2. In the makepgkinfo I am performing a fairly strict test to make sure each of the mode settings matches what chmod expects for a symbolic mode. If one or more of the modes does not fit the expression, I then abort execution.

If the 'uniq_str' method is removed, I would suggest changing the expression from '(a|[ugo]+)[=+-][rstwxXugo]{1,9}' to '(a|[ugo]+)[=+-][rstwxXugo]+' as the '{1,9}' only makes sense if there are no duplicate characters.

In installer.py, the check there is more paranoia than anything. I'm assuming that there may be invalid characters somewhere in the input so I'm removing anything that shouldn't be in a proper mode setting. Unlike the regex in 'makepkginfo', I'm not doing any checking on whether the modes are syntactically correct or not. SiInce the expression will have no side-effects on a valid modestring it can be removed without affecting anything.

3. 'appdmg_options' sounds good for the current use but I can see potential issues if the scope is expanded. Right now having this on the top-level of the pkginfo makes sense to me because, if I am understanding the appdmg installs correctly, only a single item is installed. Once multiple items are installed having a single owner/group/mode section might be extremely limited. To me, it would make sense if there was an 'item_options' or something like that associated with each item in the 'installs' section which would contain this info. I'm fairly new to the Munki codebase so I'm not sure if that would be the appropriate spot or not.

Attached is an updated patch with my suggestions from (1) and (2):
Changes:
* [makepkginfo:check_mode] Removed the 'uniq_str' method
* [makepkginfo:check_mode] Changed the mode regex from '(a|[ugo]+)[=+-][rstwxXugo]{1,9}' to '[augo]+[=+-][rstwxXugo]+'. chmod seems to be able to handle character repetition pretty well on its own
* [makepkginfo:check_mode] Removed a debug 'print' call I missed
* [installer.py:copyAppFromDMG] Removed the sanitization step when applying the modestring
* [installer.py] Removed the (now) unnecessary 're' import

[natewalck]

From [email protected] on July 23, 2010 09:46:48

I don't plan to extend the dmg-copier-thingee to copy multiple items to multiple destinations; this functionality can be achieved by either making a package, or defining multiple pkginfo items for a single disk image. This pkginfo items could even have dependencies. An example:

The Google Earth DMG contains the Google Earth application and a Google Earth Web Plug-in.

Currently the appdmg install method will install Google Earth, but cannot do anything with the plugin. Currently, if you wish to deploy the plugin, you'll have to build a package.

A more general dmg-copier thing with a single source and destination could copy Google Earth to /Applications/. Let's call the item GoogleEarth.

A second pkginfo file could cause the plugin to be copied to /Library/Internet Plug-ins/. Let's call this item GoogleEarthWebPlugin.

If GoogleEarthWebPlugin had an "update_for" key listing "GoogleEarth", simply adding "GoogleEarth" to a manifest would cause both to be installed. Or you could keep them separate, and specify that GoogleEarthWebPlugin "requires" GoogleEarth. Then each could be listed as optional installs.

[natewalck]

From [email protected] on July 23, 2010 12:42:48

guiyon -

I've incorporated your patch, and am now working on generalizing the appdmg install method to something that can install more arbitrary items from a disk image.

[natewalck]

From [email protected] on August 02, 2010 11:50:14

This has been released with munki 0.6.0.633.0 as part of the new copy_from_dmg installer type, which will replace the appdmg installer type.

Status: Fixed