2009/2/9 Ariane van der Steldt <ari...@stack.nl>: > On Mon, Feb 09, 2009 at 01:46:39AM +0100, Jesus Sanchez wrote: >> This question it's a little complicated to make. It's more a curiosity >> than a technical situation. First I will try to put the situation. >> Let's say I'm the root of a system, and one of my users (user foo) have >> his home dir with rwx privileges ( /home/foo/ have permissions 700 ) and >> I wan't to create a "black box" dir inside it's home, so I cd to >> /home/foo and do: >> >> # mkdir blackdir >> # chmod 000 blackdir >> >> At this point (as I know) the foo user isn't able to see the content of >> blackdir, but if the dir is empty he can delete it (rm -df blackdir) >> cause he have rwx on /home/foo. >> >> Someway, user foo can have information about the contents of >> blackdir: if it's empty he can 'rm -d' it, so he will know if the dir >> had or not any file. In my way of think, thats "information" about the >> dir. >> >> What is the design cause of this behaviour? I mean, It wouldn't be more >> logical the fact that if a dir have 000 permissions, the foo user >> shouldn't be able to get any kind of information about the dir? even >> something so trivial as if the dir was empty or not. > > The user is allowed to remove the directory, but only if it is empty. rm > -d expects and empty directory argument and executes the remove > operation, which the kernel will not grant if there's files in it. It's > not a design decision, but a logical conclusion of the design.
Commenting on an old thread here, but maybe this will help somebody googling the archives (and yes, most OpenBSD miscers know this of course): The reason for this behaviour --which may seem counterintuitive depending on your implicit assumptions-- is that directories are actually defined in their *parent* directory. Thus, as you correctly observed, when the user tries to remove the empty blackdir in /home/foo, they can do so, because the permissions of /home/foo are 700. If however there's a file in /home/foo/blackdir, then this will prevent /home/foo/blackdir from being removed, because the 000 permissions of blackdir prevent the file from being removed -- even if the latter has 777 permissions or is an empty subdirectory. If blackdir has 333 permissions, the user can remove the file (that has 777 permissions). However, if blackdir has 333 permissions and contains an empty subdirectory that has 000 permissions, then the user must already know or be able to guess the name of that subdirectory, because to remove it, they will need to run first rm -rf blackdir/subdirectory and then rm -rf blackdir. The easy way to thus create a persistent blackbox directory that the user cannot delete is to make sure it's never empty, for instance by doing # mkdir /home/foo/blackbox # chmod 000 /home/foo/blackbox # touch /home/foo/blackbox/.sticky Of course a blackbox would not be very useful really, unless you're trying to hide your private files in someone else's directory. *Dropboxes* however are quite useful (though not necessarily in individual users' home folders): # mkdir dropbox # chmod 333 dropbox # touch dropbox/.sticky Because the 333 permissions of the dropbox folder would in principle allow users to delete .sticky (as opposed to the above scenario where the 000 permissions of blackbox would have prevented that, as long as .sticky isn't an empty subfolder), the permissions of .sticky itself now become important, and it's probably best to do: # chmod 000 dropbox/.sticky Voila! A dropbox that users cannot delete, and whose contents users cannot list, but which they can copy files into. That's very useful e.g. for WebDAV (cf. http://openports.se/www/mod_dav ) and probably FTP servers, so people can give stuff to you, without being able to see what files others have sent you. However, be warned: This prevents them from listing the directory contents, but due to the execute (=directory traverse) permissions of the dropbox folder, people with shell access will still be able to confirm the *existence* of individual files if they can guess their file names, like so: $ ll dropbox/.sticky ---------- 1 root ropers 0 Mar 8 04:44 dropbox/.sticky $ (NB: On my systems, alias ll='ls -Fahl'.) This tells them that the file they asked to be listed does indeed exist; if the file did not exist, the above command would have resulted in an error. They wouldn't however be able to tell what --if anything-- is inside those files. So dropboxes are a nice facility that you may set up once and for all, and that people could use to copy/upload files to you and only you. However: If someone were to e.g. copy a file called "L4T35T B00TL3G M0V13.RAR" into your drop box, then it'd be entirely possible that some WIPO-RICO vigilante might be able to guess and confirm that a file of that name is indeed present on your system... regards, --ropers
