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]

Ulf <ulf.and...@gmail.com> writes:

>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]

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

[Darren Dunham]

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?

--
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]

Ulf <ulf.and...@gmail.com> writes:

>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]

Darren Dunham <ddu...@redwood.taos.com> writes:

>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]

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.

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]

In article <xoavpso7...@sun.com>,

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 <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.

This is how the sheer majority of files in any given package is
specified and delivered.

-Dan

[Daniel Rock]

Dan Foster <use...@evilphb.org> wrote:
> 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]

In article <dph2eb$2lua$1...@server.rock.net>,

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