Re: dropping setuid/setgid privileges

James Youngman wrote: > > For example, the user can write to a file that he > > does not own but which is chgrp'ed to a group that is contained among > > his supplementary groups. The program may need to write to such a file. > > If it has only the user's uid and gid, it cannot do it. So it needs >

Re: dropping setuid/setgid privileges

On Thu, Jun 11, 2009 at 10:10 PM, Bruno Haible wrote: > Shouldn't the program also call setgroups (possibly indirectly through > initgroups), in order to make sure that it can write any file that the > user can write to? That is usually necessary but not always sufficient, for example see http://

Re: dropping setuid/setgid privileges

Sergey Poznyakoff wrote: > > What is the use-case that you are considering? A setuid/setgid executable, > > or an executable run by root? > > I was considering an executable run by root. Ah, I see. That requires a different API, one that takes the target uid and gid (and supplementary groups) as

Re: dropping setuid/setgid privileges

Bruno Haible ha escrit: > What is the use-case that you are considering? A setuid/setgid executable, > or an executable run by root? I was considering an executable run by root. > And what task does it do, related to the user's data and devices? Retaining supplementary is often necessary for t

Re: dropping setuid/setgid privileges

James, Sergey, > > So we may also need to do something like this: > > > > #if HAVE_SETGROUPS > > /* Use of setgroups() is restricted to root only. */ > > if (0 =3D=3D geteuid()) > > { > > /* We're either root or running setuid-root. */ > > gid_t groups[1]; > > groups[0]

dropping setuid/setgid privileges, round 2

Just came across these two articles, which goes into the same direction as "Setuid demystified": * Dan Tsafrir, Dilma da Silva, David Wagner: The Murky Issue of Changing Process Identity: Revising "Setuid Demystified"