> Hello,
>
> I'm working in a chrooted environment like this
>
> uwsgi --module myapp --uid 1001 --gid 1001 --chroot . --home /env
> --pythonpath / -s /tmp/sock
>
> I had created the . path with debootstrap, and has all the python
> libraries correctlty and user and group 1001 exists on the base system
> but not in the chroot. Using subprocess to run 'id' and 'groups'
> commands similar to the 'Hello World' example I receive this as
> response:
>
> uid=1001 gid=1001 groups=0(root)
> 1001 root
>
> adding the 1001 user to /etc/passwd and /etc/group, it change to:
>
> uid=1001(user) gid=1001(user) groups=1001(user),0(root)
> user root
>
> In the host machine the 1001 user only belong to its own group:
> # id user
> uid=1001(user) gid=1001(user) groups=1001(user)
>
> Why is the root group added to the user?
>
> The uwsgi.py script:
>
> import subprocess
> def application(environ, start_response):
> start_response('200 OK', [('Content-Type', 'text/plain')])
> resp = subprocess.Popen(['id'], stdout=-1).communicate()[0]
> resp += '\n'
> resp += subprocess.Popen(['groups'], stdout=-1).communicate()[0]
> yield resp
>
> I noted that the enviroment variable from the console that runs uwsgi
> is mantained even after the chroot and the response has the "USER",
> "GROUP" and more variables, but even removing those the response is
> the same.
>
>
Starting from Linux 2.6.4 processes can be memmbers of multiple groups and
this behaviour is inherited after fork().
To reset them you have to use
http://linux.die.net/man/2/setgroups
I will make a patch in the next hours and i will release it in the 0.9.6.6
version tomorrow.
--
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
