[request-sponsor] sponsor request for bug 6363303
John, if you've done the contributor agreement, I can certainly help you with this putback. Bonnie Corwin wrote: > Hi John, > > I assume you mean 6363303. I'll add this to the table. > > You might want to go ahead and submit a contributor agreement. > > Then you'll be all set when someone picks this up. > > Thanks. > > Bonnie > > John Sonnenschein wrote On 09/12/06 03:39,: >> Hello, >> I've got 2 source trees in one of which bug 63633303 is fixed (yes, >> it was a search and replace, it took me all of 5 minutes). >> >> I just need someone to sign off on the code & stick it in the main tree >> >> >> >> >> ___ >> request-sponsor mailing list >> request-sponsor at opensolaris.org > > ___ > request-sponsor mailing list > request-sponsor at opensolaris.org
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
>> 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 are generally the same but need not be. An administrator CANNOT manipulate the basic set; he can manipulate the default. Making sync() privileged would violate POSIX; but with basic privileges that is not an issue because everyone gets them in the default configuration. Casper
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
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 an error >> for sync(2) but there is for 'lockfs -f'. > > I assume the above was supposed to be "there is no way to return an > error for sync(2)..." Yes I did. > It seems as though the key interest in non-root users being able to > run sync(1m) is in reaction to some perceived doom on its way (thunder > that comes a few seconds after the lightning, etc.). If sync(2) were > change to check for a privilege (PRIV_SYS_SYNC?) before calling vfs > sync(), it indeed would not return an error. However, sync(1m) could > do the same check that sync(2) does and return the appropriate error. What check ? Only the kernel (and the Xserver when TX is running) checks privileges, applications should never check privileges and make assumptions based on them. > 'lockfs -f' seems as though it would be able to get an error from > ufs_fioffs(). Yes or from the equivalent for other filesystems that implement that ioctl as well. > Does it make sense to progress with this as: > > 1) Create a new privilege PRIV_SYS_SYNC Seems as reasonable a name as any. > 2) Alter sync(2) or vfs_sync() to only perform the sync if the calling > process has PRIV_SYS_SYNC. Either is probably fine. > 3) Alter ufs_fioffs() to only perform the sync if the calling process > has PRIV_SYS_SYNC. On failure return EPERM. Yes and check ZFS and the other filesystems too. > 4) Alter sync(1m) to check for PRIV_SYS_SYNC and say "Permission > Denied" and exit with a non-zero value if the permission is not held. No applications should not check privileges, though in this case it might be okay since you know you need sys_sync to call sync(2) and if you don't have it what is the point. In the general case though one is supposed to try the operation rather than assume based on the privileges one has. > 5) Alter rc0.sh to only call sync(1M) if running in the global zone. > 6) Alter svc.startd(1M) to only call sync(2) if running in the global zone. I'll leave those to a zones expert to answer. > 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? As soon as you manipulate the privilege sets you are already operating outside of POSIX so it doesn't apply. -- Darren J Moffat
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
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 "basic set" and there's the "default set" users get when > they login; they are generally the same but need not be. > > An administrator CANNOT manipulate the basic set; he can manipulate > the default. > > Making sync() privileged would violate POSIX; but with basic privileges > that is not an issue because everyone gets them in the default > configuration. What SUSv3 seems to say is that I/Os must be scheduled before the sync completes, but the I/Os need not occur prior to the sync(2) call returning. It also says nothing about what might happen if not all of the I/Os complete, or whether the system can be shut down without all I/Os completing. So one wonders whether (in the event an unprivileged user issues a sync) you could just "schedule" the I/O to happen say, 1000 years in the future. The poorly defined spec from POSIX seems to be in conflict with how much effort we might go to in order to comply with it... Maybe there's a more detailed standards definition somewhere I've not seen? -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
