s10: /usr/ucb/ps output truncated after 79 (80)char when used by nonpriv user ?
Ulf
I see that I can no longer get more than 79 (80) char in the output from
/usr/ucb/ps when running as non privilegde user (a.k.a. non root). This
must have changed since it worked in Solaris 9, right !?
Can anyone shed some light on this ..... I heard it was to prevent
inadvertently leaking private process data ??????
reg//ulf
Casper H.S. Dik
>I see that I can no longer get more than 79 (80) char in the output from
>/usr/ucb/ps when running as non privilegde user (a.k.a. non root). This
>must have changed since it worked in Solaris 9, right !?
Yes.
>Can anyone shed some light on this ..... I heard it was to prevent
>inadvertently leaking private process data ??????
Correct. And /usr/ucb/ps is no longer a privileged process; you can
only peek at your own processes. Since /usr/ucb/ps needed to read random
data from address spaces there was a risk of leakage and that is
compounded with the risk of /usr/ucb/ps being set-uid root.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Ulf
thx, hmm ok but playing a bit I see I need proc_owner and if so I can ...
BTW does that mean bugid 5085752 is out of date too (since most of
the other ones are "closed, not fix" except this one) ... or may we wish
for this (/usr/bin/ps) in the future .....
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5085752
keep smiling
reg//ulf
Darren Dunham
> Correct. And /usr/ucb/ps is no longer a privileged process; you can
> only peek at your own processes. Since /usr/ucb/ps needed to read random
> data from address spaces there was a risk of leakage and that is
> compounded with the risk of /usr/ucb/ps being set-uid root.
Same risk with 'pargs'? If an admin wanted, would making that suid be
any less dangerous than making /usr/ucb/ps suid?
--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
roger.f...@sun.com
Ulf wrote:
> hi Casper,
>
> thx, hmm ok but playing a bit I see I need proc_owner and if so I can ...
>
> BTW does that mean bugid 5085752 is out of date too (since most of
> the other ones are "closed, not fix" except this one) ... or may we wish
> for this (/usr/bin/ps) in the future .....
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5085752
>
> keep smiling
> reg//ulf
Thanks for reminding me.
I just closed bugid 5085752 as a duplicate of 1237528.
And 1237528 had already been closed as "will not fix".
Roger Faulkner
Sun Microsystems
roger.f...@sun.com
Darren Dunham wrote:
> Casper H.S. Dik <Caspe...@sun.com> wrote:
> > Correct. And /usr/ucb/ps is no longer a privileged process; you can
> > only peek at your own processes. Since /usr/ucb/ps needed to read random
> > data from address spaces there was a risk of leakage and that is
> > compounded with the risk of /usr/ucb/ps being set-uid root.
>
> Same risk with 'pargs'? If an admin wanted, would making that suid be
> any less dangerous than making /usr/ucb/ps suid?
Same risk. We ship neither command as set-id to root.
We have no control over what admins do.
Roger Faulkner
Sun Microsystems
Casper H.S. Dik
>hi Casper,
>thx, hmm ok but playing a bit I see I need proc_owner and if so I can ...
>BTW does that mean bugid 5085752 is out of date too (since most of
>the other ones are "closed, not fix" except this one) ... or may we wish
>for this (/usr/bin/ps) in the future .....
>http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5085752
We could still do that for processes you can control.
Casper H.S. Dik
>Casper H.S. Dik <Caspe...@sun.com> wrote:
>> Correct. And /usr/ucb/ps is no longer a privileged process; you can
>> only peek at your own processes. Since /usr/ucb/ps needed to read random
>> data from address spaces there was a risk of leakage and that is
>> compounded with the risk of /usr/ucb/ps being set-uid root.
>Same risk with 'pargs'? If an admin wanted, would making that suid be
>any less dangerous than making /usr/ucb/ps suid?
We left the code that deals with being set-uid in /usr/ucb/ps on purpose.
There's no code which protects you in pargs.
Note that you should NOT make /usr/ucb/ps set-uid; rather make
/usr/ucb/*/ps set-uid.
James Carlson
> We left the code that deals with being set-uid in /usr/ucb/ps on purpose.
>
> There's no code which protects you in pargs.
>
> Note that you should NOT make /usr/ucb/ps set-uid; rather make
> /usr/ucb/*/ps set-uid.
Those files are delivered as type 'f', which means they shouldn't be
altered by users.
If you do that, you'll essentially end up with an unsupportable
system. Installing a patch that includes those files will cause your
changes to disappear, and you can potentially suffer other ill effects
from having the packaging database information mis-matching the actual
file system state.
--
James Carlson, KISS Network <james.d...@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
David Combs
James Carlson <james.d...@sun.com> wrote:
>Casper H.S. Dik <Caspe...@Sun.COM> writes:
>> We left the code that deals with being set-uid in /usr/ucb/ps on purpose.
>>
>> There's no code which protects you in pargs.
>>
>> Note that you should NOT make /usr/ucb/ps set-uid; rather make
>> /usr/ucb/*/ps set-uid.
>
>Those files are delivered as type 'f', which means they shouldn't be
>altered by users.
Stupid question here: what is type 'f'?
I looked at file.man, and then /etc/magic, and saw nothing
like a plain "f".
So the type business you are talking about is evidently
orthogonal to that dealt with by "file".
Thanks for any illumination!
David
Dan Foster
> In article <xoavpso7...@sun.com>,
>
> Stupid question here: what is type 'f'?
'man prototype' -- basically, he's referring to a certain field in one
of the files comprising a package; it's got meta information about the
package contents itself.
'f' here refers to a file or directory that is *not* expected to change;
Solaris will perform and store a checksum on it at installation time.
This is how the sheer majority of files in any given package is
specified and delivered.
-Dan
Daniel Rock
> In article <dpf8c0$m9j$1...@reader2.panix.com>, David Combs <dkc...@panix.com> wrote:
>> In article <xoavpso7...@sun.com>,
>>
>> Stupid question here: what is type 'f'?
>
> 'man prototype' -- basically, he's referring to a certain field in one
> of the files comprising a package; it's got meta information about the
> package contents itself.
>
> 'f' here refers to a file or directory that is *not* expected to change;
> Solaris will perform and store a checksum on it at installation time.
The problem isn't the checksum (setting the setuid bit doesn't change the
checksum - just the file mode). But probably the change might be overwritten
by a patch.
No problems - just re-apply your changes after patch install. I haven't seen
a patch failed to apply if a "required" file was missing or has been changed.
Or mustn't I from now on do
rm -f /etc/rc3.d/S75seaport
after Solaris installation?
Ok, this package was probably mispackaged. Usually scripts in /etc/rc?.d
are of type "l" with hardlinks to /etc/init.d (I prefer symlinks though).
--
Daniel
David Combs
Daniel Rock <ab...@deadcafe.de> wrote:
>Dan Foster <use...@evilphb.org> wrote:
>> In article <dpf8c0$m9j$1...@reader2.panix.com>, David Combs
><dkc...@panix.com> wrote:
Thanks for the info!
David