On 17 Apr 2008, at 20:38, A.D.F. wrote: > Alvaro Lopez Ortega wrote: >> On 17 Apr 2008, at 00:06, A.D.F. wrote: >>> Stefan de Konink wrote: >>>> . . . >>> >>> OK, if user is root, then readability has to be verified >>> explicitely before opening the file. >> >> In my understanding, file system access permission checks belongs to >> the operating system. Running a program as root user implies a number >> of things: it can open a low port, it can jail itself, it can change >> system limits, AND it can read every file in the system. That is how >> Unix systems work. >> >> That's why Cherokee supports user changing, and all the modern >> operating systems include a 'web server user' such as www-data, httpd >> or www. >> >>> Indeed here some parametric policy could be added, >>> i.e. access only files readable by world, by group, by user. >> >> I'm not sure of this at all. Running servers as root is highly >> discouraged because of this kind of problems. By adding those rules >> we >> would be duplicating a work that the underling operating system will >> perform anyway, which means, the server would be slower and the only >> thing that we would get is to slightly improve the behavior of the >> server under a certain -let's call it- "misconfiguration"; or at >> least: 'not recommended' configuration. >> >> IMO the best thing we could do is to warn the user if the server runs >> as root. Maybe cherokee-admin could pop a red, flashy warning message >> if the server is configured to run as root. So, even if it is tougher >> I would try to educate people rather than "fix" Cherokee for hiding >> some of the potential problems of running a server as super-user. > > Yes, but even if you run a Web Server with a user not equal to root, > you may want to let the web server to serve only certain static files, > i.e. those that are: > - readable by others; > - readable by group. > > Imagine to have two checkbox (per server or per virtual server) > for the above two possibilities. > > If you check the first option, > then a static file has to be readable by others > in order to be served by Cherokee. > > You only need to use: > > chmod o+r file-name(s) > or > chmod o-r file-name(s) > > to enable or disable access to selected files / directories. > > This is very useful because it allows you to fine grade > the accessibility of files that can be sent to clients by Cherokee. > > If none of the above filters are selected then > it is enough that at least one readable bit (user, group, others) > is on to let Cherokee to serve a file / directory. > > Of course, in practice, there is no overhead in applying > such filters.
I may be missing something.. but, if you don't want to allow cherokee to send a file, you would only have to change its permissions and the web server wouldn't need to know about it. In fact, the patch that you committed to 0.6 would only work on legacy environments, and it would be source of problems if ACLs are used. For example, a file permissions could be 000 but at the same time, it could include an ACE allowing the web server user to read it anyway. The usual solution is to call access() to check whether the program is allowed to access the file, but in the case of Cherokee I do not think it is worth using it because of the performance penalty. I would rather keep it trying to read it and handling the failure in case it could access the file. -- Greetings, alo. _______________________________________________ Cherokee mailing list [email protected] http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee
