minor installation-related issues

[sjk]

A few observations:

* All files/directories in the SuperDuper! package are world (and group) writable.

* Running the built-in updater changes the group ID of files to group staff.

* The image background in the distribution package says:

To install or update:
Drag to Applications and run!

The "Copy applications, sharing non-Apple" copy script contains:


<dict>
<key>Directive</key>
<string>symlink</string>
<key>Item</key>
<string>Applications/Utilities/SuperDuper!</string>
</dict>
Probably best for the location to be consistent?

[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). I'm not sure why the group is changed to staff, though: we'll take a look at that and see what we can fix.

Yes, the image does say drag to Applications (though you can put it anywhere, really -- we're trying to suggest, not insist) -- but the real problem there is the script, which shouldn't have that entry in it at all any more. We'll get rid of it.

Thanks!

[sjk]

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):

% 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 3535751084Whatever 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.

[dnanian]

We're going to have to re-examine exactly what we can and can't do in this situation. We tried a bunch of things that didn't work, and found the user had to delete the bundle even though they owned it, which was more than a bit weird.

Yeah, and we'll get rid of the stupid .DS_Store file, which should have automatically been done by XCode, but must not have been...

[sjk]

Thanks, Dave. There are probably differences between 10.2 and 10.3 behavior to consider, too.

[dnanian]

Yep, probably. It's not hugely high priority, but we'll definitely take a look next cycle.