On 18 Apr 2008, at 23:00, Gunnar Wolf wrote: > A.D.F. dijo [Fri, Apr 18, 2008 at 09:16:04PM +0000]: >>> If we went the let's-try-to-make-root-safe way, we would have to >>> fix a >>> bunch of additional issues. For instance, it wouldn't make sense to >>> chroot the server if it runs as root, but again, that is not a >>> problem >>> that we ought to face. >> >> I understand the reasoning, >> but indeed above proposal is not about fixing root security, >> but to introduce a new and inexpensive way to limit web access >> to normal user's files in systems that don't use ACLs. >> >> Think about a user that runs Cherokee but that don't want >> to give public access to a few files / directories >> placed below web root and that is not convenient >> to place somewhere else because the server is chrooted, >> it runs with an unpriviledge user, there are programs >> that use those specific paths, etc. > > Umh, for a non-root user, if you have a chmod 000 directory in the > path, the system won't try to enter: > > 0 [EMAIL PROTECTED] mkdir -p /tmp/1/1/1/1/1 > 0 [EMAIL PROTECTED] chmod 000 /tmp/1/1/1 > 0 [EMAIL PROTECTED] ls -l /tmp/1/1/1/1 > ls: cannot access /tmp/1/1/1/1: Permission denied > > So you'd be patching this only for the very corner case when you are > running as root _and_ are trying to hide something from root. Does it > make sense?
Well, and the worst thing is that, even if we tried to make root execution safe we would most likely fail. That isn't a battle we ought to face, actually. Thinking of the system architecture, the operating system is only the layer that should make the decision on whether a file is accessible. I do agree with ADF on trying to make users life easier by adding new features (with no performance penalty), however I do not think that checking the permission on the server would be a good thing because all the architectural and technical reason we have commented previously. IMO our best option is to add more global checks to ensure that the user gets a big flashy warning whenever he tries to configure the server in a non-recommended way (such as running it as root). -- Greetings, alo. _______________________________________________ Cherokee mailing list [email protected] http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee
