[request-sponsor] Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Hi!
Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to
/tmp/$LOGNAME/") - patch is included in the RFE...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Roland Mainz wrote:
> Hi!
>
>
>
> Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to
> /tmp/$LOGNAME/") - patch is included in the RFE...
This will I believe need an ARC case since it is a change in default
behaviour. It also should be done for all shells not just ones
that read /etc/profile.
Since I do this myself in my own .profile I feel duty bound to stand up
to the plate and by your sponsor for this. So sign me up for putback
sponsor and I'll be ARC case submitter too.
--
Darren J Moffat
[request-sponsor] bug fixes awaiting sponsor
Hi, We have six bug fixes awaiting a sponsor. One has been on the list for more than two months and two have been on the list for more than a month. Please take a look and see if you can pick one up. http://opensolaris.org/os/bug_reports/request_sponsor Thank you. Bonnie
[request-sponsor] Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Darren J Moffat wrote:
> Roland Mainz wrote:
>> Hi!
>>
>>
>>
>> Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to
>> /tmp/$LOGNAME/") - patch is included in the RFE...
>
> This will I believe need an ARC case since it is a change in default
> behaviour. It also should be done for all shells not just ones
> that read /etc/profile.
>
> Since I do this myself in my own .profile I feel duty bound to stand up
> to the plate and by your sponsor for this. So sign me up for putback
> sponsor and I'll be ARC case submitter too.
>
Good idea (I use this myself :-)). Should the directory be created
700 by default?
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber.eng.sun.com http://blogs.sun.com/barts
[request-sponsor] Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
>Darren J Moffat wrote:
>> Roland Mainz wrote:
>>> Hi!
>>>
>>>
>>>
>>> Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to
>>> /tmp/$LOGNAME/") - patch is included in the RFE...
>>
>> This will I believe need an ARC case since it is a change in default
>> behaviour. It also should be done for all shells not just ones
>> that read /etc/profile.
>>
>> Since I do this myself in my own .profile I feel duty bound to stand up
>> to the plate and by your sponsor for this. So sign me up for putback
>> sponsor and I'll be ARC case submitter too.
>>
>
>Good idea (I use this myself :-)). Should the directory be created
>700 by default?
There's a risk in setting $TMPDIR and making it mode 700; the risk
is that programs started under a different uid may start to fail.
But it should either by mode 1777 (to mitigate that risk) or 700
for privacy.
Casper
[request-sponsor] Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Casper.Dik at Sun.COM wrote: >>> Since I do this myself in my own .profile I feel duty bound to stand up >>> to the plate and by your sponsor for this. So sign me up for putback >>> sponsor and I'll be ARC case submitter too. >>> >> Good idea (I use this myself :-)). Should the directory be created >> 700 by default? > > There's a risk in setting $TMPDIR and making it mode 700; the risk > is that programs started under a different uid may start to fail. pkgadd is one of those programs. > But it should either by mode 1777 (to mitigate that risk) or 700 > for privacy. Or honour the umask ? -- Darren J Moffat
[request-sponsor] Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Casper.Dik at Sun.COM wrote:
>> Darren J Moffat wrote:
>>> Roland Mainz wrote:
Hi!
Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to
/tmp/$LOGNAME/") - patch is included in the RFE...
>>> This will I believe need an ARC case since it is a change in default
>>> behaviour. It also should be done for all shells not just ones
>>> that read /etc/profile.
>>>
>>> Since I do this myself in my own .profile I feel duty bound to stand up
>>> to the plate and by your sponsor for this. So sign me up for putback
>>> sponsor and I'll be ARC case submitter too.
>>>
>> Good idea (I use this myself :-)). Should the directory be created
>> 700 by default?
>
> There's a risk in setting $TMPDIR and making it mode 700; the risk
> is that programs started under a different uid may start to fail.
>
Yeah, you'll notice that if you try to su to root and run installers
that run pkgadd internally. I use this method, and the StarOffice 8
installer failed quite mysteriously until I realized it was just an
instance of that problem and reset TMPDIR to something else.
Dave
[request-sponsor] Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
>Yeah, you'll notice that if you try to su to root and run installers >that run pkgadd internally. I use this method, and the StarOffice 8 >installer failed quite mysteriously until I realized it was just an >instance of that problem and reset TMPDIR to something else. This, unfortunately, kills the whole idea in my mind. (I vaguely remembered similar issues from the past) And while we all agree that not being able to use $TMPDIR should not cause a horrid failure in any application, I'm afraid that we'd need to fix those bugs first. (Strange, though, since installers usually run as root; so this was with an NFS $TMPDIR?) Casper
[request-sponsor] Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Casper.Dik at Sun.COM wrote: >> Yeah, you'll notice that if you try to su to root and run installers >> that run pkgadd internally. I use this method, and the StarOffice 8 >> installer failed quite mysteriously until I realized it was just an >> instance of that problem and reset TMPDIR to something else. > > This, unfortunately, kills the whole idea in my mind. > (I vaguely remembered similar issues from the past) > > And while we all agree that not being able to use $TMPDIR should > not cause a horrid failure in any application, I'm afraid that > we'd need to fix those bugs first. > > (Strange, though, since installers usually run as root; so this > was with an NFS $TMPDIR?) > No, it was just running the installer within a setuid wrapper using a local $TMPDIR set to 700. Not really a recommended practice, so I don't know that it's fatal to the idea, just pointing out that it does in fact happen for some cases. Dave
[request-sponsor] 4967733 and 6400646
* Richard Lowe [2006-10-29 12:29]: > Mike Gerdts wrote: > >The real motivation for this and the other fix I just sent to > >request-sponsor was to figure out how to use mercurial. As such, if > >there is any goofiness with the patch or would you prefer "hg bundle" > >over "hg export", please let me know. One particular thing that I was > >looking into was the impact of "zfs clone" instead of "hg clone" (no > >impact seen so far...). Any wisdom that can be shared on that front > >would likewise be appreciated. > > I've sent patches via 'hg export' previously without anyone having > complained. Perhaps that's just them being polite though :) I would be interested to hear from sponsors if patches generated from "hg export" are proving easy to apply. Comments? (I am assuming that having the up-to-date ON repository is helping contributors, but comments otherwise would be interesting as well...) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
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)..." 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. 'lockfs -f' seems as though it would be able to get an error from ufs_fioffs(). > > For the zones case maybe it can not be in the default set of privileges > given to a zone, so by default they get to run more quickly. Just like > with many other privileges the admin can choose the limitset of > privileges the zone has. True enough. Does it make sense to progress with this as: 1) Create a new privilege PRIV_SYS_SYNC 2) Alter sync(2) or vfs_sync() to only perform the sync if the calling process has PRIV_SYS_SYNC. 3) Alter ufs_fioffs() to only perform the sync if the calling process has PRIV_SYS_SYNC. On failure return EPERM. 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. 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. 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? Mike -- Mike Gerdts http://mgerdts.blogspot.com/
