Does the Finder break permissions rules?

[Snowball]

I just did something I don't think the Finder is supposed to have permission to do.

Say you have 2 users on your OS X installation. You log in as yourself (an admin user), and drag a file from your Desktop to the other users /Public/Drop Box folder. So far so good, right? You're not supposed to be able to modify (or view) this folder, right? Wrong. Try undoing the operation in the Finder. The file you copied over will remove itself from the other user's supposedly one-way folder.

Is this considered a glitch, "feature", or does the Finder have some kind of strange permissions built in to handle this situation?

 

[scruffy]

Actually, it's not doing anything it shouldn't be able to. The directory is world-writable (anyone can put stuff in it, or remove stuff from it), world-executable (anyone can make it their current working directory, for purposes of e.g. writing a file), just not world readable (no one but the owner can get a list of its contents).

So, what the Finder does there is perfectly legitimate. To confirm, try this in terminal:

Can't see what's in it:

cd /Users/someoneelse/Public/Drop\ Box
ls

Can work with files there (including deleting it) if you know they're there by some other means, and have permissions on the files themselves:

cd /Users/someoneelse/Public/Drop\ Box
echo "some text" > afile.txt
cat afile.txt
ls
ls afile.txt
rm afile.txt
ls afile.txt

Where it is misbehaving, though, is here: Try mounting a disk on another computer, as a registered user on that computer, via afp. Then, look into some other user's drop box on that computer - you can see everything in there!

 

[Snowball]

So as long as one knows the exact filename one can do whatever he wants to the file within the write-only directory. There's probably a good reason for it, but it seems kind of like a security flaw to me, because if you have confidential information in a drop box someone could guess the filename and delete the confidential file... oh well.

 

[onan]

Well, this is a somewhat unavoidable limitation to using a shared/public account for confidential information. If you want the data to be more secure, use an actual user account.

There are a couple of non-obvious ways that unix permissions interact with directories. Read permission on the directory controls your ability to get a listing of the directory's contents, but has nothing to do with your ability to read the files themselves; their own read permission bits control that.

Similarly, write permission on the directory controls the ability to create, delete, and rename files within the directory. Thus, if you had write permission to the directory, but not to a particular file, you could still delete that file, though you couldn't directly edit it. This is essentially an artifact of the way directories work, rather than being designed for human interaction, and thus frequently surprises people.