I thought a DROP BOX was write only!

A

aicul

Registered
I was trying out the drop box folders in OSX and stumbled upon this. Is this normal?

I understand a drop box is WRITE ONLY for the "generic" user. And OSX actually warns me that if I move a file into this folder I will not be able to recover it.

Now for the catch. If, for example in textedit, I use SAVE AS and select a drop box, textedit will save the file no problem. This is normal as textedit is WRITING to the drop box.

Now I quite textedit, re-launch it and select the file I saved earlier in the drop box from the RECENT FILES menu. Textedit opens the file no problem and displays the contents.

In my eyes, this is a READ activity in a folder that is WRITE ONLY. :eek:

Is this normal?
 
Drop box is read and write for the Owner,
and *[write]*only(drop) for Group and Other.

If you save a file to YOUR drop box, you can still see it,
open it, write to it, or delete it.

Now I quite textedit, re-launch it and select the file I saved earlier in the drop box from the RECENT FILES menu. Textedit opens the file no problem and displays the contents.
Click to expand...
Unless i am mistaken - In the above instance, textedit is reading and opening the recent file from memory and not from the drop box you saved it to.

*[EDIT]*: changed read only to write only
 
Either way, Text Edit should not be able to open a file from a drop-box of which it shouldn't see the contents... Security-wise, I mean... So, aicul, was it your drop-box or another user's?
 
Hmm, looks like a limitation of the basic Unix file permissions system.

Directory permissions:
r - list files (ls)
w - add files
x - access files

Now, you'd think setting it to -w- would be sufficient, but without -wx, you can't actually create files in the directory for some reason. But with -wx, you can still access a file in the directory for which you have access permission if you know the full path to the file. So if I put something into a drop box, I can still get at it with "cp" or "open" or the like. Seems kind of counter-intuitive if you ask me.
 
fryke said:
Either way, Text Edit should not be able to open a file from a drop-box of which it shouldn't see the contents... Security-wise, I mean... So, aicul, was it your drop-box or another user's?
Click to expand...

I am pretty sure text edit is veiwing the file from memory and not from the drop box.

I also noticed that when you save a file to the drop box using the "save as" method from within text edit, you do not get the warning message ("you do not have permission to see the results of this operation. Do you want to continue?")

I also discovered that you can use sudo -ls in terminal and veiw the contents of other users drop boxes. :confused:
 
First of all, of course with sudo anyone can access everything and do whatever he/she wishes :p

As for the read only for Drop Box it is ONLY for the rest of the users of a given system and not for the owner... The owner can do whatever he wants with his/her Drop Box :D

TextEdit and almost all apps when opening something from the Recent menu they are actually opening those items from their locations and not from memory... Well, they somewhat use the cache/swap memory but that's another story ;)

Now, if ANYONE has a Drop Box that other users can access it as read/write too, then he/she ASAP needs to repair permissions!!!ASAP!!!! :rolleyes:
 
Well, i actually tried what i thought he was describing - i used "save as" to save a text file into another users drop box, and after closing and re-opening text edit the "open recent" function allowed me to veiw the text file.
(the permissions on the drop box were set properly - i checked)

As far as using sudo - my point was that the drop box is
not very secure if any user listed in the /etc/sudoer
file or any admin user can veiw the contents.
 
g/re/p said:
Well, i actually tried what i thought he was describing - i used "save as" to save a text file into another users drop box, and after closing and re-opening text edit the "open recent" function allowed me to veiw the text file.
(the permissions on the drop box were set properly - i checked)
Click to expand...

Yeah, like I said, it's pretty much a limitation of the basic Unix permissions. In order to set the directory so that a user can create files in it, the user will also have to be able to read said files. And theoretically, if another user's UMASK is such that files he creates in the drop box are world readable, other users will be able to access it if they know the full path. If you want a decent drop box, you'll have to do some other trickery (i.e. launching another process that escorts the file off to a truly inaccessible directory and changes its permissions accordingly).

I'm not sure if 10.4 will support full-blown ACL-style security (can't find info right now), but if it does, the drop boxes will probably work a bit more like one would expect.
 
definitely not from memory!

I was thinking it had to do with you being the owner of the file, but it does not.

If you (user A) save to the drop box of user B, then use a third user (C) to save another file with the same name to the user B's drop box, overwriting the first file and then as A open recent, you will get the new file.
 
OK - one vote for definitely not from memory. :)
An explanation as to why this is so would be helpful.

man is this getting complicated! Let me be more specific - user A uses the "save as" function in text edit to save a text file into user B's drop box - user A closes and re-opens text edit and, using the "open recent" function, is able to veiw the text file that was just saved into user B's drop box - which supposedly should not be possible.
*There never was a user C in this scenario.

* user A also did not get the warning message that pops up when dragging a file into another users drop box.

beorning said:
definitely not from memory!

I was thinking it had to do with you being the owner of the file, but it does not.

If you (user A) save to the drop box of user B, then use a third user (C) to save another file with the same name to the user B's drop box, overwriting the first file and then as A open recent, you will get the new file.
Click to expand...
 
g/re/p said:
man is this getting complicated! Let me be more specific - user A uses the "save as" function in text edit to save a text file into user B's drop box - user A closes and re-opens text edit and, using the "open recent" function, is able to veiw the text file that was just saved into user B's drop box - which supposedly should not be possible.
*There never was a user C in this scenario.
Click to expand...

You'd think that user A wouldn't be able to access the file he put in the drop box - after all, shouldn't a drop box be write-only? But because of limitations of the user/group/other read/write/execute permissions that OS X uses, that cannot be implemented easily.

The drop box will have permissions write and execute for others, but no read. This allows users to create files in the directory, and access files in the directory, but not list the directory contents. The file the user creates in the drop box will be owned by himself, with read and write permission for himself. It'll look something like this:

Drop Box/ - User A - rwx-wx-wx
Drop Box/MyFile.txt - User B - rwxr-xr-x

Since user B has permission to access the file he just created, he can still open it if he knows the location and path name (which Text Edit has cached in the Open Recent list). Make sense?

Currently, I don't see any way to allow users to create and write to files in a directory, but disallow reading files in the directory. It looks like 10.4 will support ACL permissions, which are much more powerful, so that could change.


* user A also did not get the warning message that pops up when dragging a file into another users drop box.
Click to expand...

It's probably just a feature of the Finder. If Text Edit isn't doing it, then it just means the generic Open and Save dialogs in the system libraries don't bother with the warning.


In other words, everything is working fine. It's just that "fine" is not quite what most would expect. ;-)
 
Yes, it's just a courtesy that the Finder extends you, to warn you like that.

If you want a real write-once-only drop box function, send e-mail.

I don't know if it's really a privacy problem - if you dropped the file there, you presumably already know what it is, and if you made a mistake in it, it should be alright for you to correct it.

Now, this assumes that people know that they will have to set the permissions of a file the way they want them (e.g. maybe change the permissions for the group, or the group ownership) before they drop off the file...
 
Wow, did think my question would raise such a discussion.

As per the drop box I was testing. Its the one created automatically by OSX for each user in public. I thought I had messed up privs so I did run repair privs and also created a new test user (and hence his drop box) to check. Same results.

scruffy said:
I don't know if it's really a privacy problem - if you dropped the file there, you presumably already know what it is, and if you made a mistake in it, it should be alright for you to correct it.
Click to expand...

I believe there is an issue here. If OSX says "your drop box contents can only be modified by you". I may be tempted to edit files that are submitted to my drop box without moving them to another folder. However, the person that submitted the file WILL be able to read my mods.

Also when you submit a file to a drop box, it is "finished". Mods (to correct errors) should require a 2nd submission.

scruffy said:
If you want a real write-once-only drop box function, send e-mail.
Click to expand...
Point taken.

davidbrit2 said:
Drop Box/ - User A - rwx-wx-wx
Drop Box/MyFile.txt - User B - rwxr-xr-x

Since user B has permission to access the file he just created, he can still open it if he knows the location and path name (which Text Edit has cached in the Open Recent list). Make sense?
Click to expand...

Yes. Does this mean that read access to the file put in the drop box is only limited to user B and the drop box owner?
 
aicul said:
Yes. Does this mean that read access to the file put in the drop box is only limited to user B and the drop box owner?
Click to expand...

It depends on the permissions user B set on the file (likely automatically). In that example, it's like this:

Owner (user B): read, write, execute
Group: read, execute
Everyone: read, execute

The default umask is 022, meaning files will be created with permissions 755 (like the example). So if another user knows where to get the file, he should be able to do it.
 
Actually, if the permissions are 755, and you don't own it, then not even you, the owner of the dropbox, can modify the file. You can move it about (all you're actually modifying is the directories the file is in), delete it (again, nothing is written to the file, it's just the link to the file in a directory you own that's deleted), you could open it and make an exact copy of its contents, and modify that copy.

But you can't technically change it, because it remains owned by the person who dropped it there.

I say 'technically' - if you edit it and try to save it, you will be told the file is read-only, and would you like to overwrite it (at least, that's what TextEdit does). If you do, you can notice the inode number will have changed - the original file has not been changed, it has been removed, and a new one with the same name has been made in its place (both possible because you own the directory the file is in). This new file will be owned by you, not by the person who dropped the file in the first place.

Indeed, anyone can do this - the directory is world writable, so anyone can remove a link that the directory contains:

0 20:21mark@poppacrow:~/Public/Drop Box % pwd
/Users/mark/Public/Drop Box
0 20:21mark@poppacrow:~/Public/Drop Box % sudo -u ami -s
[poppacrow:~/Public/Drop Box] ami% echo foo > bar
[poppacrow:~/Public/Drop Box] ami% exit
exit
0 20:23 mark@poppacrow:~/Public/Drop Box % ls
bar
0 20:23 mark@poppacrow:~/Public/Drop Box % sudo -u alice -s
[poppacrow:~/Public/Drop Box] alice% rm bar
override rw-r--r-- ami/mark for bar? y
[poppacrow:~/Public/Drop Box] alice% exit
exit
0 20:23 mark@poppacrow:~/Public/Drop Box % ls
0 20:23 mark@poppacrow:~/Public/Drop Box %
 
scruffy said:
Indeed, anyone can do this - the directory is world writable, so anyone can remove a link that the directory contains:

0 20:21mark@poppacrow:~/Public/Drop Box % pwd
/Users/mark/Public/Drop Box
0 20:21mark@poppacrow:~/Public/Drop Box % sudo -u ami -s
[poppacrow:~/Public/Drop Box] ami% echo foo > bar
[poppacrow:~/Public/Drop Box] ami% exit
exit
0 20:23 mark@poppacrow:~/Public/Drop Box % ls
bar
0 20:23 mark@poppacrow:~/Public/Drop Box % sudo -u alice -s
[poppacrow:~/Public/Drop Box] alice% rm bar
override rw-r--r-- ami/mark for bar? y
[poppacrow:~/Public/Drop Box] alice% exit
exit
0 20:23 mark@poppacrow:~/Public/Drop Box % ls
0 20:23 mark@poppacrow:~/Public/Drop Box %
Click to expand...

This is actually easy to prevent using the "stick bit".

From http://www.kingcomputerservices.com/unix_101/security_basics_part_2.htm:
The third bit controls the behavior of directories and is popularly called the stick bit. When this bit is set on a directory, the only people who can delete or rename files from that directory are root and the owner of the directory, regardless of any other permission a user's been granted. This is frequently used on temporary and work directories where many users need to be able to write to the directory, but where no one should be allowed to rename or delete anyone else's files.
Click to expand...

So chmod your drop box to 1733, and users won't be able to screw with the other users' files in the drop box. In fact, the /tmp directory is set up similarly:
Code: 
[/] dave$ ls -ld /private/tmp
drwxrwxrwt   18 root     wheel         612 Nov  3 00:04 /private/tmp
Note the "rwt" in the Others field.

I'm not sure if you can specify the stick bit algebraically, like in "chmod g+rx", and frankly I'm way too tired to care. ;-)
 
Sorry to keep this going, but this is very interesting to me.
(Good idea on the sticky bit)

I tried accessing the other users drop box via go to folder
from the finders go drop-down menu and used the exact
path - it would not work, so it looks like the drop box does work as i expected it should.

As far as using the GUI to access the file by using its full path,
i cannot find a way to do so - so i am satisfied that the drop box
is secure enough for its intended use.

Most standard accounts do not have access to terminal, so that route is not really an issue either.
 
g/re/p said:
Most standard accounts do not have access to terminal, so that route is not really an issue either.
Click to expand...

Huh? Only the most restricted accounts using the simple finder would not have access. All standard accounts can use it just fine.
 
You must log in or register to reply here.
Back
Top