On Fri, Nov 17, 2006 at 01:11:26PM +0100, Olaf van der Spek wrote: > Sounds like the wrong definition.
There is no choice as it is enforced by the kernel: if you can open() the directory, then you can list its contents, otherwise not. > So what is the purpose of using 751 (besides security through obscurity)? This is "security through obscurity" to exactly the same degree as password authentication is. Sure, you can send the rest of your life trying to find out what files exist in the directory by trying every possible strings as a file name, but that is essentially the same as mounting a brute-force password guessing attack against say an LDAP server. This threat model is well understood and if you care about it then simply monitoring CPU usage and I/O activity will quickly reveal the offending user. Using the kernel's auditing framework AFAIK it would not be difficult to write a tool that automatically checks for this kind of abuse. > Is a Debian system required to use Apache with user dirs? No, why would it? On the other hand, what do you mean by "user dirs" - mod_userdir or something else? For example we used an external mapping program with mod_rewrite instead of mod_userdir. > That doesn't sound right either. > With PHP you can easily read those files from another user/vhost if > they're world-readable. I thought that mentioning ACLs would make it clear that the files are no longer world readable, they are readable only for a very limited set of users. If you allow users to have unchecked PHP scripts running under the web server's user ID on a real multi-user system then you're welcome to shoot yourself in the foot. If you allow different vhosts to run untrusted PHP files under the same user ID then you're welcome to shoot yourself in the other foot. Gabor -- --------------------------------------------------------- MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences --------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]