[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)

2006-11-27 Thread Jeffrey Hutzelman
On Thursday, November 02, 2006 10:03:25 PM -0600 Mike Gerdts wrote: > However, sync(1m) could > do the same check that sync(2) does and return the appropriate error. Ugh! No, thank you. I already see enough trouble with programs that think they "know" what the privilege model is and refuse

[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)

2006-11-03 Thread casper....@sun.com
>> Assuming we do steps 1 and 2 above, do we get into any problems with >> POSIX compliance if the default basic privilege set does not include >> PRIV_SYS_SYNC? There is no such thing as a "default basic set". There's a "basic set" and there's the "default set" users get when they login; they

[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)

2006-11-03 Thread Darren J Moffat
Mike Gerdts wrote: > On 10/30/06, Darren J Moffat wrote: >> James Carlson wrote: >> Why, other than the returning an error we already have 5 such privileges >> in the basic set. Now in each of those cases (proc_info, proc_session, >> proc_fork, proc_exec, file_link_any) there is a way to return a

[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)

2006-11-03 Thread Dan Price
On Fri 03 Nov 2006 at 10:34AM, Casper.Dik at sun.com wrote: > > >> Assuming we do steps 1 and 2 above, do we get into any problems with > >> POSIX compliance if the default basic privilege set does not include > >> PRIV_SYS_SYNC? > > There is no such thing as a "default basic set". > > There's a

[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)

2006-11-02 Thread Mike Gerdts
On 10/30/06, Darren J Moffat wrote: > James Carlson wrote: > Why, other than the returning an error we already have 5 such privileges > in the basic set. Now in each of those cases (proc_info, proc_session, > proc_fork, proc_exec, file_link_any) there is a way to return an error > for sync(2) but

[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)

2006-10-30 Thread casper....@sun.com
>Why, other than the returning an error we already have 5 such privileges >in the basic set. Now in each of those cases (proc_info, proc_session, >proc_fork, proc_exec, file_link_any) there is a way to return an error >for sync(2) but there is for 'lockfs -f'. And it's exactly what the basic

[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)

2006-10-30 Thread Darren J Moffat
James Carlson wrote: > Darren J Moffat writes: >> Dan Price wrote: >>> I know that at some point the performance guys wanted to make sync's by >>> non-root users do nothing, but IIRC it was deemed too risky or something. >>> Maybe we should go do that for Nevada. Anyone in request-sponsor land >>>

sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)

2006-10-30 Thread Darren J Moffat
Dan Price wrote: > I know that at some point the performance guys wanted to make sync's by > non-root users do nothing, but IIRC it was deemed too risky or something. > Maybe we should go do that for Nevada. Anyone in request-sponsor land > have some background info they could point us at? For wa

[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)

2006-10-30 Thread James Carlson
Darren J Moffat writes: > Dan Price wrote: > > I know that at some point the performance guys wanted to make sync's by > > non-root users do nothing, but IIRC it was deemed too risky or something. > > Maybe we should go do that for Nevada. Anyone in request-sponsor land > > have some background in

[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)

2006-10-30 Thread Nicolas Williams
On Mon, Oct 30, 2006 at 04:14:33PM +0100, Casper.Dik at Sun.COM wrote: > >Why, other than the returning an error we already have 5 such privileges > >in the basic set. Now in each of those cases (proc_info, proc_session, > >proc_fork, proc_exec, file_link_any) there is a way to return an error