[opensuse] nginx uid:gid
13.1 Hi We have a nginx test going. Yast created a uid:gid, nginx:nginx Is that if you are running apache at the same time? If we go live, is there any reason nginx shouldn't run as: wwwrun:www ? Thanks -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn wrote:
13.1 Hi We have a nginx test going. Yast created a uid:gid, nginx:nginx Is that if you are running apache at the same time?
If we go live, is there any reason nginx shouldn't run as: wwwrun:www
No prob, unless you do the same with another piece of SW. Several packages have tended to overlap on UID or GID and it, generally speaking, is more secure to put each in their own group. That way you could, say, give out access to nginx to someone, w/o them having access to the output of ntop (which also was switched to it's own user/group away from overlapping on wwwrun:www. From what I understand, wwwrun:www is to be use for a web server. But you can reuse it if you know you'll never need the standard functions... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2014-03-26 at 05:13 -0700, Linda Walsh wrote:
lynn wrote:
13.1 Hi We have a nginx test going. Yast created a uid:gid, nginx:nginx Is that if you are running apache at the same time?
If we go live, is there any reason nginx shouldn't run as: wwwrun:www
No prob, unless you do the same with another piece of SW.
Several packages have tended to overlap on UID or GID and it, generally speaking, is more secure to put each in their own group. That way you could, say, give out access to nginx to someone, w/o them having access to the output of ntop (which also was switched to it's own user/group away from overlapping on wwwrun:www.
From what I understand, wwwrun:www is to be use for a web server.
But you can reuse it if you know you'll never need the standard functions...
Hi Thanks, that sounds good. We've an app where the devs want to rw stuff to their public_html folder. Apache writes as wwwrun:www whereas the 13.1 nginx writes as nginx:nginx: they can't edit their files any longer. Rather than go through all the public_html folders on the fs, I'd rather just change nginx.conf to wwwrun:www. We've tried it and it works but I doubt it's as simple as that. I've usually overlooked something. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn wrote:
Thanks, that sounds good. We've an app where the devs want to rw stuff to their public_html folder. Apache writes as wwwrun:www whereas the 13.1 nginx writes as nginx:nginx: they can't edit their files any longer.
I don't see a problem with the way you have it setup -- especially since in your case, it sounds like nginx is being run *instead* of apache, so keeping the UID/GID the same as what it was before provides a more seamless upgrade. I appreciate having daemons running under their own separate user id -- and not a generic one for all, since a security problem in one daemon gives access to all daemons files running under the same UID/GID. Having each in it's own UID/GID allows for finer access control as well. Another way you might think about 'someday', is to use ACL's and a "default acl" on the directories that can give extended access by group or user name *OR* just use setGID on the directories and have their group set to 'www', so all files created in them will end up in 'www'. Would still need to make sure processes that execute in those dirs have umasks set to something like 002. But if what you have works, no need to change it till the next upgrade... ;-) (BTW -- To go through all folders and set such bits, (GID or ACLs), one would likely use 'find' (all files & dirs owned by 'www', for example and pipe that into xargs...but you likely already know that)). Cheers... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2014-03-26 at 17:52 -0700, Linda Walsh wrote:
lynn wrote:
Thanks, that sounds good. We've an app where the devs want to rw stuff to their public_html folder. Apache writes as wwwrun:www whereas the 13.1 nginx writes as nginx:nginx: they can't edit their files any longer.
I don't see a problem with the way you have it setup -- especially since in your case, it sounds like nginx is being run *instead* of apache, so keeping the UID/GID the same as what it was before provides a more seamless upgrade.
I appreciate having daemons running under their own separate user id -- and not a generic one for all, since a security problem in one daemon gives access to all daemons files running under the same UID/GID. Having each in it's own UID/GID allows for finer access control as well.
Another way you might think about 'someday', is to use ACL's and a "default acl" on the directories that can give extended access by group or user name *OR* just use setGID on the directories and have their group set to 'www', so all files created in them will end up in 'www'. Would still need to make sure processes that execute in those dirs have umasks set to something like 002.
But if what you have works, no need to change it till the next upgrade... ;-)
Yeah, I'm surprised. Simply changing the uid:gid in nginx.conf seems to have done it. We'd tried setfacl-ing nginx rwx on the public_html folders too but again, it's no good for the stuff that's already there with wwwrun:www.
(BTW -- To go through all folders and set such bits, (GID or ACLs), one would likely use 'find' (all files & dirs owned by 'www', for example and pipe that into xargs...but you likely already know that)).
Yes, good idea. Got it. But hoping we won't have to. We've down time Sunday. We plan to go live with it and leave it in place for Monday morning with lots of practise switching between nginx and apache during the downtime. In fact, it's a little more complicated than that. The switch is from apache/mod-php5 to nginx/php-fpm Thanks for your clear explanations. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Linda Walsh -
lynn