On Thu, Feb 14, 2013 at 08:58:10AM +0100, Roberto De Ioris wrote:
> 
> > On Tue, Mar 06, 2012 at 04:23:25PM +0000, Sigurd Høgsbro wrote:
> >> Ran into a file permission problem whilst trying to setup Trac (0.12.3)
> >> on a
> >> Linux box (Ubuntu Lucid 10.04) with TracGit plugin to run under uWSGI
> >> (1.0.4),
> >> with the Git repo's managed by Gitolite. Gitolite runs under git:git,
> >> uWSGI/
> >> Trac runs under trac:trac. The trac user is a member of the git group,
> >> and I've
> >> verified that I can read the Git control-files as the trac user (after a
> >> 'su -
> >> trac').
> >>
> >> When running the Trac code under uWSGI, TracGit complains that it cannot
> >> read
> >> the repo control files. Running the same code under tracd (in HTTP
> >> mode), it
> >> works. I added some trace in PyGit.py, and found that when run under
> >> uWSGI, the
> >> uid/gid is set correctly but the supplementary group list is empty. I
> >> eventually found this was caused by the call in utils.c:577 to
> >> setgroups(0,
> >> NULL), after the call to setgid().
> >>
> >> After some Googling I found the correct solution is calling
> >> initgroups(3)
> >> instead of calling setgroups(2) - see links below for details.
> >>
> >>   •
> >> [1]http://www.gnu.org/software/libc/manual/html_node/Setting-Groups.html
> >>   •
> >> [2]http://stackoverflow.com/questions/1489579/linux-id-no-squash-root
> >>   • [3]http://www.palecrow.com/chroot-jail-paper.html
> >>   •
> >> [4]http://code.google.com/p/modwsgi/source/browse/mod_wsgi/mod_wsgi.c#10197
> >>
> >> Note: There are calls to setgroups() in both utils.c and emperor.c. I
> >> only
> >> tested this in utils.c.
> >
> > So I am not sure why this bug didn't get more attention. Currently I am
> > hitting this same bug (well, not me, but a fedora user), check this
> > comment:
> >
> >
> 
> 
> That bug was fixed years ago (uWSGI 1.0 is a real old [unmaintained] tree).

This is 1.2.6, but I guess I should push the 1.4 branch to fedora soon.

> 
> Your problems instead is in the usage of the tyrant mode. Tyrant mode
> expect you run the Emperor as root, otherwise it will not be able to drop
> privileges on vassals (the tyrant mode, enforce the vassal to ignore
> uid/gid supplied by the user).

Ah that makes sense, gotcha.

> 
> From the bug report the user is running the Emperor as uwsgi:uwsgi and
> then asking for tyrant mode (this will not work, unless you add some
> capability for it, but albeit this is what i use in my company i have
> never seen that practice being followed)
> 

Thanks Roberto!

> 
> -- 
> Roberto De Ioris
> http://unbit.it
> _______________________________________________
> uWSGI mailing list
> [email protected]
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Attachment: pgpCBxURT0UAB.pgp
Description: PGP signature

_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to