On 19 May 2024 11:11 -0400, from monn...@iro.umontreal.ca (Stefan Monnier): >> If you have read permission on a directory but *not* execute permissions, >> then the only thing you can do is read the contents of that directory -- >> the filenames and their inode numbers. You cannot stat() the files, >> so you can't see who owns them or even what kind of files they are. >> Just their names. > > Never found a situation where this as useful.
Put the user that a HTTP server runs in into each user's group, and set g=x on each user's home directory plus ~/public_html. (Your choice whether you want g=rx or g=x on the latter.) The web server process is now able to access web content from within the user's home directory without needing to run anything as root (possibly after dropping privileges after binding to ports 80 and 443), and all this without giving anyone else any access into other users' home directories. Sure, something like www.example.com/~username mapping to a directory inside username's home directory isn't that common a pattern these days, but it used to be _very_ common. And since it's exposed more or less directly to untrusted network inputs, it's nice to be able to make the HTTP server drop privileges as much as possible. This generalizes to any process having reason to descend into a directory but not reason to enumerate the contents of the directory it needs to descend into. Another example would be a process wanting to manage its own /var/log/$subsystem directory itself; it doesn't need to do anything to anything in /var/log, it only needs to be able to descend into its own directory. Yes, you _can_ do it in other ways. But the above is definitely _one_ way. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
