- - wrote: > Thank you for your very good explanation! I could not find anything > nearly as good as this in the internet! But that message is now on the internet. :-) > Another question came up while reading your message: > Wouldn't it then be better to give ownership of '/usr/local/var/lib/cherokee' > to 'www-data:staff', instead of 'root:www-data'? That way 'staff' would still > have access to that folder, while 'www-data' would be possible to read > and write in that directory? I see you are now thinking about this in the right way. There are permissions associated with the user and permissions associated with the group. The web server process is one entity and you as a user are another. The web server can line up with the user permission and you can line up with the group permission and both can have access. Or the reverse. Either would be a valid combination. Another alternative is that you could add yourself to the www-group too and then in addition to staff for other files you could also access the www-group directories through that group permission. Either way. At this late-for-me-time I can't decide if there is any advantage one way or the other. Probably your suggestion above. > Another solution would be adding user 'www-data' to group 'staff', but > I presume that Cherokee (or any other software) would be access to files the > service should not care about? That is not a good combination. Think about compartmentalization of risk. If you have a network facing program such as a web server and it is attacked by a hostile and cracked then ask how much damage can that hostile person do? They will have all of the permissions available to the web process user and group. Having group staff access would allow a cracker to have access to most of /usr/local. Not good. Because of this it is desired to limit the permissions of the web server process as much as possible. That is why the web server process runs as the www-data:www-data user and group. It keeps it from having any permission except for those files and directories for which it was specifically granted access and no others. Bob
Attachment:
signature.asc
Description: Digital signature