Quote:
Originally Posted by dnanian
We made the files and directories world writable to allow for drag-and-drop update -- otherwise, you get an error when you try (and authenticating doesn't always seem to work).
|
For the first drag-and-drop install the installing account will need write permission to the target directory, correct? After that, are you saying any drag-and-drop
updates could then be done by
any user, even though SuperDuper!'s parent directory may be unwritable to that user?
I've done all SD! installs/updates while logged in as an admin account drag-and-drop installs to /Applications work without authenticating, but the updater required authentication to run its package installer (just this morning, for the current version).
Re: group staff. The bom shows files as being gid 20 (staff):
Code:
% lsbom Archive.bom | head -5
. 40755 501/20
./.DS_Store 100644 501/20 6148 2264754351
./SuperDuper!.app 40777 501/20
./SuperDuper!.app/Contents 40777 501/20
./SuperDuper!.app/Contents/Info.plist 100666 501/20 2093 3535751084
Whatever group is chosen would probably differ from the original one after a drag-and-drop install/update. Not sure about the uid (501) since that matches my admin account uid. Maybe uid 0 (root) and gid 80 (admin) are better choices for "systemish" software like this (even if a followup drag-and-drop would change 'em)? Oh, and maybe remove that .DS_Store file?
Maybe drag-and-drop installs/updates and package updates with secure file/directory permissions, from admin and/or non-admin accounts, aren't possible with certain combinations. Since I've done all installs/updates from an admin account I'm not as aware of issues with them from a non-admin account. From that admin-centric install/update view I see SuperDuper! as one of the few apps on my system with world-writable permissions and it seemed ironic for backup software to be that way.