Permissions whee!

As in any good mystery, the question is who done it? MacNN reports a flaw in Tiger, Leopard in which an authenticated copy operation gives the destination files (the copies) the ownership of the logged-in user, not of the name they used to authenticate. The question is, which user did the copy?

Let’s say there’s a system with Alice Administrator and Richard Regular-User. Richard downloads a new application from the intarwebs, and wants to put it in /Applications (though why? Why can’t he just put it in ~/Applications like a good little user? Never mind). The thing is, he doesn’t have the right to do that. Finder presents him with an authentication dialogue, and no matter how many times he enters his username and password correctly, he can’t acquire that right. However, he sees Alice walking past in the corridor and asks her to enter her admin credentials. For whatever reason, she agrees – now Alice has authenticated and Alice has acquired the right to copy the files. So even though Richard requested the copy, it was actually Alice who performed it. Therefore Alice created the files at the destination, so they should be owned by Alice.

The only thing which muddies the waters (and leads to the conflict of convenience vs. security which is described in that article) is that in many, or indeed most, cases on OS X where this will arise, Alice and Richard are actually the same person – Sammy the Single (Security-conscious, hence separating their use of the system into regular and admin accounts) User. It’s a convenience that as Richard wanted the files copied, Richard now owns the copy – but this defeats the point of Richard existing, which is that Sammy doesn’t want to be able to change /Applications without being warned.

Interestingly the same question doesn’t get asked of the sudo command – it’s clear that if I type sudo ditto /Applications/ it’s the super-user who does the work.

This entry was posted in FTFF, security. Bookmark the permalink.

One Response to Permissions whee!

  1. meh. You’re still reading MacNN? ;-)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.