Alvaro Lopez Ortega wrote:
>
> 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.
OK, then a configuration option (compile time)
should suffice to enable/disable this feature in 0.6.2 and higher
(default: enabled, because this is what 95% of users want).
> 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.
Yes, I know about what you are saying,
but lots of systems out there don't have filesystems with ACLs,
so I think that this simple feature could help at least 80% - 90%
of Cherokee users.
A warning about the unusefulness of this feature
with filesystems having ACLs and with sysadmins that tweak them,
would suffice; if you have and use ACLs, you don't want to use
this feature.
So, the final solution could be:
[ ] enable readability bit filters (only legacy systems, NO ACLs)
NOTE: if enabled, at least 1 readability bit (user,group,world)
has to be set in order to allow access to static files
[ ] filter to require "world bit" readability
[ ] filter to require "group bit" readability
I am not really advocating for including this feature into 0.7
but we could start to think about it.
--
Nick Name: A.D.F.
E-Mail: <adefacc () tin ! it>
E-Mail-Format: Plain Text only (please); view using font Courier New
--
_______________________________________________
Cherokee mailing list
[email protected]
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee
