Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: As I've understood the conclusion of this thread, we want a 
: sysctl, and we want it open as default.  This patch should
: do that.
: 
: Once Warner nods in the vertical direction it will be committed.

The head is oscillating with and against the gravity well of the
planet earth while I'm in the standing position.

Looks good to me.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Poul-Henning Kamp]

As I've understood the conclusion of this thread, we want a 
sysctl, and we want it open as default.  This patch should
do that.

Once Warner nods in the vertical direction it will be committed.

Poul-Henning


Index: kern/kern_exec.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.103
diff -u -r1.103 kern_exec.c
--- kern_exec.c 1999/11/16 20:31:51 1.103
+++ kern_exec.c 1999/11/25 18:32:41
@@ -77,6 +77,9 @@
 SYSCTL_LONG(_kern, OID_AUTO, ps_arg_cache_limit, CTLFLAG_RW, 
 &ps_arg_cache_limit, "");
 
+int ps_argsopen = 1;
+SYSCTL_INT(_kern, OID_AUTO, ps_argsopen, CTLFLAG_RW, &ps_argsopen, 0, "");
+
 /*
  * Each of the items is a pointer to a `const struct execsw', hence the
  * double pointer here.
Index: kern/kern_proc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v
retrieving revision 1.61
diff -u -r1.61 kern_proc.c
--- kern_proc.c 1999/11/21 19:03:09 1.61
+++ kern_proc.c 1999/11/25 18:31:51
@@ -633,7 +633,7 @@
if (!p)
return (0);
 
-   if (p_trespass(curproc, p))
+   if ((!ps_argsopen) && p_trespass(curproc, p))
return (0);
 
if (req->newptr && curproc != p)
Index: miscfs/procfs/procfs_status.c
===
RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs_status.c,v
retrieving revision 1.18
diff -u -r1.18 procfs_status.c
--- procfs_status.c 1999/11/21 19:03:19 1.18
+++ procfs_status.c 1999/11/25 18:32:22
@@ -183,7 +183,7 @@
 * Linux behaviour is to return zero-length in this case.
 */
 
-   if (p->p_args && !p_trespass(curp, p)) {
+   if (p->p_args && (ps_argsopen || !p_trespass(curp, p))) {
bp = p->p_args->ar_args;
buflen = p->p_args->ar_length;
buf = 0;
Index: sys/proc.h
===
RCS file: /home/ncvs/src/sys/sys/proc.h,v
retrieving revision 1.92
diff -u -r1.92 proc.h
--- proc.h  1999/11/21 19:03:20 1.92
+++ proc.h  1999/11/25 18:31:16
@@ -384,6 +384,7 @@
 extern int whichidqs;  /* Bit mask summary of non-empty Q's. */
 
 extern u_long ps_arg_cache_limit;
+extern int ps_argsopen;
 
 struct proc *pfind __P((pid_t));   /* Find process by id. */
 struct pgrp *pgfind __P((pid_t));  /* Find process group by id. */

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Garance A Drosihn]

At 8:03 AM + 11/24/99, Brian Somers wrote:
> > This was discussed close to death before the changes were committed,
> > and the current behaviour (restricted access) has been agreed by
> > general consensus to be the most appropriate.
>
>My reading of the thread was ``I'm going to cache ps args to stop all
>the delving into user space to do a ps'', ``but what about the -e
>option'', ``ok, I'll make that inaccessible unless you have
>permission''.
>
>I stopped reading the -e thread because I believe it's a good thing to
>restrict this.  I completely missed that the conversation had moved
>on to ``hey, who needs ps args anyway'', and I'm sure that given the
>number of messages posted about the -e restriction, others did too.

For what it's worth, this is also what happened to me.  I tuned out
the '-e' thread once I had said my two-bits on the topic (and I was
pretty sure the end result would come out OK with me).  I did not
notice the topic of also removing argv from 'ps'.

Removing 'ps -e' ability is fine by me (though I'd prefer that I
could see the environment of "my own" processes).  I can see how
that would improve security, even if it occasionally means a very
slight loss in user convenience.

I am not at all happy with the idea of removing argv from 'ps'
listings.  I have scripts which use that information, and it
sounds like the only way to fix those scripts would make things
WORSE for security.  This does not benefit "user convenience"
and it does not benefit "security".

At the same time, I remember many years ago when another OS that
I worked on was trying for security classification.  I can see
that this behavior *could* be a good idea for situations which
want to be really paranoid about security.  I would not mind
this behavior as a system-wide option, but I'd certainly want
the default setting to match current behavior.


---
Garance Alistair Drosehn   =   [EMAIL PROTECTED]
Senior Systems Programmer  or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Wes Peters]

Warner Losh wrote:
> 
> In message <[EMAIL PROTECTED]> Peter Wemm writes:
> : 
> : In a dedicated server role, again it might be appropriate to default
> : it to "open" (dedicated server being something like a squid box),
> : again there will be a couple of sysadmin type users or people who
> : have to monitor things.  Hiding information gains nothing there
> : either.
> 
> I disagree with this, but that is because I've rarely seen a totally
> dedicated server.  A simple fileserver that does nothing else would
> want to be open in this respect since few people have accounts.
> 
> : In other roles, including something like a shell server box with presumably
> : hostile users (you reasonably have to assume this), you want everything you
> : possibly can to be locked down.
> 
> Firewall, dialup boxes, dns servers, etc are good candidates to be
> locked down.

Firewall, web, dns, news, etc. servers are good candidates to be open because 
there should not be any "normal" user accounts on them, only administration 
accounts.  And darned few of those.  I think this is what Peter was getting
at.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Brian Somers]

> > In the last episode (Nov 23), Lyndon Nerenberg said:
> > > After you verify that this change isn't going to break things that
> > > assume they can see the *argv list via ps(1). I.e. lightning bolts
> > > that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant
> > > style, but sometimes is the only workable solution.

Indeed.  There's always a better way, but I've seen countless 
production systems that do this all the time.  In fact, we've only 
recently done away with all the (sysv) ``ps -ef''s where I work.

> > That won't be affected, because anyone that has kill rights to the
> > process will also see the full processname.  Now that I think about it,
> > I can't come up with a case where this is really bad.  If you're doing
> > ps'es with intent to kill arbitrary processes (in the name of debugging
> > or whatever), you're probably already root.

Or maybe you're a sysadm that's smart enough to use sudo and not run 
around with root liability in normal life.

> This was discussed close to death before the changes were committed, 
> and the current behaviour (restricted access) has been agreed by 
> general consensus to be the most appropriate.

My reading of the thread was ``I'm going to cache ps args to stop all 
the delving into user space to do a ps'', ``but what about the -e 
option'', ``ok, I'll make that inaccessible unless you have 
permission''.

I stopped reading the -e thread because I believe it's a good thing to 
restrict this.  I completely missed that the conversation had moved 
on to ``hey, who needs ps args anyway'', and I'm sure that given the 
number of messages posted about the -e restriction, others did too.

> Making this behaviour tunable would be bad; it adds another option 
> increasing complexity, and with the proposed default in most cases an 
> admin tightening up a system would never know about it in the first 
> place, rendering it useless.
> 
> I'd strongly recommend leaving things they way they are.

This change in behaviour will break production systems, and I'm 
pretty sure that the breakage will be worked around with a quick 
``chmod 4555 /bin/ps''.  Is this what we want ?  Where I work, we've 
just done away with all the sysv ``ps -ef'' calls in the system.  It 
took several weeks and a lot of testing.  I'd be pretty miffed if the 
OS shoved this down my throat prematurely as a requirement just be
cause I upgraded without knowing of the change.

Further, I assert that this change is just wrong !

Why does setproctitle() now require root privileges if nobody can 
see the results ?  This is dumb, as the only uid that we're 
protecting against is the user that's running setproctitle() !

sendmail/nfs/ppp etc can no longer give normal users information on 
what's going on via the command args (ok, you can figure out the nfs 
args).

System monitoring scripts will now have to run as root.

In fact, why do the processes owned by other users show up at all ?  
The ``you don't need to see their args'' argument can equally apply 
to needing to see the entire process you can always kill -0 a 
process if you need to know if it's running or maybe on second 
thoughts, we should restrict kill -0 - why should people have this 
functionality anyway ?

I believe the knob is required and should default to the way things 
were.

Well, that's my opinion.  I'll calm down now.

> -- 
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: So please explain the logic you want implemented once people have
: stopped haggeling about it, it is rather trivial.

OK.  I'll likely state what I'd like to see as a patch.

: I pressume we want the same policy for /proc/*/cmdline as for the
: sysctl ps(1) uses ?

Yes.  I'll firm this up later today and send an exact proposal out so
we can kill this.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Warner Losh writes:
>: sef has sent me patches that I've not had a chance to review that
>: appear to implement this.
>
>Actually, these patches do something else.  My mistake for reading
>them before caffeine.

So please explain the logic you want implemented once people have
stopped haggeling about it, it is rather trivial.

I pressume we want the same policy for /proc/*/cmdline as for the
sysctl ps(1) uses ?

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Warner Losh writes:
: sef has sent me patches that I've not had a chance to review that
: appear to implement this.

Actually, these patches do something else.  My mistake for reading
them before caffeine.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Peter Wemm writes:
: For example, in "workstation" mode, the reasonable default is "open",
: because typically there is one user on the box (other than root) and that
: person has root access.  Excessive hiding info from that user just means
: that they'll have to use root more, or will give up the idea of using a mortal
: user entirely and run everything as root (a Really Bad idea, think of Windoze
: and viruses etc etc).

True.

: In a dedicated server role, again it might be appropriate to default
: it to "open" (dedicated server being something like a squid box),
: again there will be a couple of sysadmin type users or people who
: have to monitor things.  Hiding information gains nothing there
: either.

I disagree with this, but that is because I've rarely seen a totally
dedicated server.  A simple fileserver that does nothing else would
want to be open in this respect since few people have accounts.

: In other roles, including something like a shell server box with presumably
: hostile users (you reasonably have to assume this), you want everything you
: possibly can to be locked down.

Firewall, dialup boxes, dns servers, etc are good candidates to be
locked down.

: Oh for ACL's, privilige attributes, etc.  It would solve this sort of thing
: nicely so that you could allow admin users to see what's going on
: (including a ps -ax and see what the users are running) without having to
: constantly (ab)use root and the dangers of overusing that.

sef suggested this be a procfs mount option.  I think I like this more
than the sysctl option, but don't strong opinion either way (sysctl is
more like most of the rest of the system, while a mount option would
be harder to change on the fly).  Having it be a mount option would
make it possible to have a GID that the files are "owned" by that
could be 'operator' so that operators can see the args, and possibly
other things.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: In message <[EMAIL PROTECTED]>, Warner Losh writes:
: 
: >Not all will agree with this, and it is a change from the past so
: >there needs to be a sysctl to control this.  And given that it is a
: >radical change from the past, it needs to default to open.
: 
: Now, I can't tell if you wore the security-master hard-hat in this
: email or not, and I see some quite divergent australian positions,
: so I will sit tight until I see a little bit more of a consensus.

It was with my hat on, but lemme explain a little how I got here.

Before the recent changes to ps, procfs used to not disclose the
command line.  When it was modified to be used with a ps that didn't
need to be set[gu]id it lost this.  I wanted to see it restored for
those people that had depended on this, but realized that it would be
unpopular (and unnecessary) for many people.  As part of the change to
restore the behavior, I wanted the sysctl.  Now that it is half there,
I'd like the other half to complete the picture.

The reason that it was a big deal to me was that on the old system if
you turned off the setuidness of ps, w, et al you would block
disclosure of args/env vars, etc, but still have access to process
lists.  With the change, there was no way to do this which represented
a weakening of the overall system on the whole, despite the strenth
added by taking the setgid bit off ps.

sef has sent me patches that I've not had a chance to review that
appear to implement this.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Garrett Wollman]

< said:

> This was discussed close to death before the changes were committed,

Where, and by whom?  I don't recall seeing any such discussion on
-security.

> and the current behaviour (restricted access) has been agreed by 
> general consensus to be the most appropriate.

Agreed by whom?  Remember POLA?

> Making this behaviour tunable would be bad; it adds another option 

Indeed; it should be reverted completely.  Portable programs may not
rely on their argv[] being ``secret''.  Portable sysadmins rely on
argv[] not being ``secret''.

Having bogus behavior such as this encourages sysadmins to do all
their work as root -- a very Bad Thing.  Not only that, it violates 20
years of UNIX tradition.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED]  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Peter Wemm]

Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
> : Warner ?

[.. reasons for and against ..]

> Not all will agree with this, and it is a change from the past so
> there needs to be a sysctl to control this.  And given that it is a
> radical change from the past, it needs to default to open.
> 
> Warner

Without wanting to get "please send patches" (I fear sysinstall as much as
anyone), I think it would be really nice to create a place where we can set
a default 'security profile' or something which arranges for these sorts
of things to be set according to the role of the machine.

For example, in "workstation" mode, the reasonable default is "open",
because typically there is one user on the box (other than root) and that
person has root access.  Excessive hiding info from that user just means
that they'll have to use root more, or will give up the idea of using a mortal
user entirely and run everything as root (a Really Bad idea, think of Windoze
and viruses etc etc).

In a dedicated server role, again it might be appropriate to default it to
"open"  (dedicated server being something like a squid box), again there will be
a couple of sysadmin type users or people who have to monitor things.  Hiding
information gains nothing there either.

In other roles, including something like a shell server box with presumably
hostile users (you reasonably have to assume this), you want everything you
possibly can to be locked down.

Oh for ACL's, privilige attributes, etc.  It would solve this sort of thing
nicely so that you could allow admin users to see what's going on
(including a ps -ax and see what the users are running) without having to
constantly (ab)use root and the dangers of overusing that.

Cheers,
-Peter



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew Dillon writes:

>I'm trying to figure out how what started as a fix to a panic turned into
>such a big mess.  And I don't even think the panic has even been fixed ---
>it's just been made more obscure.

The panic hasn't been fixed, as has been repeatedly stated, but at least
a SMP machine doesn't panic when you run the 3rd command they teach you in 
any "UNIX for dummies" book.

>In otherwords, nothing ps does blocks.  I can't imagine how changing 
>the way arguments are fetched by encumbering procfs with even more 
>junk would generate a sufficient boost in performance to be either 
>noticeable visually or worth doing at all.

Matt, lets talk about this when you have examined the code in some detail.

>It would be nice if the procfs panics were fixed, but not at the cost
>of all of this.

The procfs panics are not fixed, I know that Allan Cox has looked at it.

Poul-Henning

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Warner Losh writes:

>Not all will agree with this, and it is a change from the past so
>there needs to be a sysctl to control this.  And given that it is a
>radical change from the past, it needs to default to open.

Now, I can't tell if you wore the security-master hard-hat in this
email or not, and I see some quite divergent australian positions,
so I will sit tight until I see a little bit more of a consensus.

Poul-Henning

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: Warner ?

Like I've said in private mail to many different people on this issue,
there needs to be a sysctl which controls this, and it needs to be
open by default.

There are many cases where unwanted information is disclosed
inadvertantly by these arguments.  It invades the privacy of the users
to do so.  I don't want anybody to find out that I'm sending mail to
[EMAIL PROTECTED] because they can see my ps args, for example, or that my
chat script is doing stupid things and putting the password on the
command line.  or if I'm aiding law enforcement looking for the string
"SecreTTWarEzz" to see who is posting them from my machine, I don't
want anyone to know what I'm looking for.  People generally take care
to not include sensitive information on the command line, but
sometimes this can't be helped.

Not all will agree with this, and it is a change from the past so
there needs to be a sysctl to control this.  And given that it is a
radical change from the past, it needs to default to open.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Warner Losh]

In message <[EMAIL PROTECTED]> Forrest Aldrich writes:
: Why does ps not show the full path on 4.0 as in 3.3?
: (for non-root users)

Because you have caught things in the middle of a change.  There will
be a sysctl that will control this behavior shortly.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Matthew Dillon]

:> > and people who need to hide it can set it to "close" to do so.
:> 
:> Please.  Thank you.
:> 
:> Not everyone wears the sysadmin hat with the face shield and gas mask,
:> as much as it may currently be in style.  If it can work both ways,
:> even better.
:
:Definately!  This is NOT AN ACCEPTABLE CHANGE BY DEFAULT!
:
:Cheers,
:-Peter

I'm trying to figure out how what started as a fix to a panic turned into
such a big mess.  And I don't even think the panic has even been fixed ---
it's just been made more obscure.

There is a big difference between -e, which very few people use and which
is an obvious security risk simply because people do not realize it is
available, and displaying argv from a user-run ps which everyone is used
to doing.

When I first suggested removing -e I did so both for security reasons and
because it would have been trivial to do.  What we have at the moment is
something entirely different.

I would be for removing -e, but I would be adamantly opposed to restricting
the display of command line arguments - not even with an opt-in sysctl.  
It's just added baggage.  And I don't see much point in trying to make ps 
and top run faster.  They are plenty fast enough already (well, maybe not
top, but that's for other reasons unrelated to the display of command
line arguments).   ps *already* delves (or delved) into kvm to retrieve
command line arguments only for processes not swapped out, meaning that
running ps never causes processes or data to be swapped in unless you
specify the 'f' option.   

In otherwords, nothing ps does blocks.  I can't imagine how changing 
the way arguments are fetched by encumbering procfs with even more 
junk would generate a sufficient boost in performance to be either 
noticeable visually or worth doing at all.

It would be nice if the procfs panics were fixed, but not at the cost
of all of this.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Peter Wemm]

Christopher Masto wrote:
> On Wed, Nov 24, 1999 at 12:54:15AM +0100, Poul-Henning Kamp wrote:
> > I'm personally leaning towards the opinion that the argv is public
> > property and should be visible, but then again, I can see the point
> > in hiding it in some circumstances.
> > 
> > I'll stick a sysctl in there which defaults to the "open" position
> > and people who need to hide it can set it to "close" to do so.
> 
> Please.  Thank you.
> 
> Not everyone wears the sysadmin hat with the face shield and gas mask,
> as much as it may currently be in style.  If it can work both ways,
> even better.

Definately!  This is NOT AN ACCEPTABLE CHANGE BY DEFAULT!

Cheers,
-Peter



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

bogus kern_proc.c change (Re: ps on 4.0-current)

[Peter Wemm]

Dan Nelson wrote:
> In the last episode (Nov 23), Lyndon Nerenberg said:
> > After you verify that this change isn't going to break things that
> > assume they can see the *argv list via ps(1). I.e. lightning bolts
> > that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant
> > style, but sometimes is the only workable solution.
> 
> That won't be affected, because anyone that has kill rights to the
> process will also see the full processname.  Now that I think about it,
> I can't come up with a case where this is really bad.  If you're doing
> ps'es with intent to kill arbitrary processes (in the name of debugging
> or whatever), you're probably already root.

It's this bogus change to kern/kern_proc.c.  If you back this out it should
work as expected.

@@ -631,7 +633,7 @@
if (!p)
return (0);
 
-   if (!PRISON_CHECK(curproc, p))
+   if (p_trespass(curproc, p))
return (0);
 
if (req->newptr && curproc != p)

Cheers,
-Peter



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Mike Smith]

> In the last episode (Nov 23), Lyndon Nerenberg said:
> > After you verify that this change isn't going to break things that
> > assume they can see the *argv list via ps(1). I.e. lightning bolts
> > that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant
> > style, but sometimes is the only workable solution.
> 
> That won't be affected, because anyone that has kill rights to the
> process will also see the full processname.  Now that I think about it,
> I can't come up with a case where this is really bad.  If you're doing
> ps'es with intent to kill arbitrary processes (in the name of debugging
> or whatever), you're probably already root.

This was discussed close to death before the changes were committed, 
and the current behaviour (restricted access) has been agreed by 
general consensus to be the most appropriate.

Making this behaviour tunable would be bad; it adds another option 
increasing complexity, and with the proposed default in most cases an 
admin tightening up a system would never know about it in the first 
place, rendering it useless.

I'd strongly recommend leaving things they way they are.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Christopher Masto]

On Wed, Nov 24, 1999 at 12:54:15AM +0100, Poul-Henning Kamp wrote:
> I'm personally leaning towards the opinion that the argv is public
> property and should be visible, but then again, I can see the point
> in hiding it in some circumstances.
> 
> I'll stick a sysctl in there which defaults to the "open" position
> and people who need to hide it can set it to "close" to do so.

Please.  Thank you.

Not everyone wears the sysadmin hat with the face shield and gas mask,
as much as it may currently be in style.  If it can work both ways,
even better.
-- 
Christopher Masto Senior Network Monkey  NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Forrest Aldrich]

I seem to recall that conversation here in the mailing list.

How about a system configuration variable that determines what info
like ps (and friends) can access?

Personally, I would just prefer to leave it be.   There are too many other
potential problems with scripts and such that depend upon the info
PS provides.  *shrug*  :)


_F


At 12:54 AM 11/24/99 +0100, Poul-Henning Kamp wrote:
>In message <[EMAIL PROTECTED]>, Brian Somers writes:
> >> In the last episode (Nov 23), Brian Somers said:
> >> > $ ps jtva
> >> > USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
> >> > root   222 1   222 9dac400 Is+   va0:00.01  (getty)
> >> > $ sudo ps jtva
> >> > USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
> >> > root   222 1   222 9dac400 Is+   va0:00.01 
> /usr/libexec/getty Pc tt
> >> > $ head -1 /etc/motd
> >> > FreeBSD 4.0-CURRENT (HAK) #9: Mon Nov 22 01:09:55 GMT 1999
> >> >
> >> > This looks a bit wrong
> >>
> >> Now that does look weird.  After a bit more investigation, it looks
> >> like you can only get the full commandline of your own processes.  Root
> >> can see all commandlines.
>
> >Any comments Poul ?  Is this anything to do with the recent command
> >line buffering ?
>
>Yes, I changed it to this behaviour at warners asking (I think he had
>the security-meister hard-hat on at the time).
>
>I'm personally leaning towards the opinion that the argv is public
>property and should be visible, but then again, I can see the point
>in hiding it in some circumstances.
>
>I'll stick a sysctl in there which defaults to the "open" position
>and people who need to hide it can set it to "close" to do so.
>
>Will this satisfy everybody ?
>
>Warner ?
>
>--
>Poul-Henning Kamp FreeBSD coreteam member
>[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
>FreeBSD -- It will take a long time before progress goes too far!



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Dan Nelson]

In the last episode (Nov 23), Lyndon Nerenberg said:
> After you verify that this change isn't going to break things that
> assume they can see the *argv list via ps(1). I.e. lightning bolts
> that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant
> style, but sometimes is the only workable solution.

That won't be affected, because anyone that has kill rights to the
process will also see the full processname.  Now that I think about it,
I can't come up with a case where this is really bad.  If you're doing
ps'es with intent to kill arbitrary processes (in the name of debugging
or whatever), you're probably already root.

-- 
Dan Nelson
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Lyndon Nerenberg]

> "David" == David Malone <[EMAIL PROTECTED]> writes:

David> I guess it goes with the "stop ps showing the environment"
David> changes.  If you remove one it makes sense to remove the
David> other.

After you verify that this change isn't going to break things that
assume they can see the *argv list via ps(1). I.e. lightning bolts
that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant
style, but sometimes is the only workable solution.

Where this could be an issue is binaries with multiple names. E.g.
if bar is a symlink to foo, and you execute bar, ps (old style)
reports:

83158  p0  S  0:00.00 bar (foo)

I *suspect* in the new scheme when running non-root, you don't see
bar show up. If that's the case, we've broken working code.

Now, if instead printing *argv[] follows the -e semantics I posted to
the list a couple of days ago, all should be well.

--lyndon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[David Malone]

On Tue, Nov 23, 1999 at 11:52:49PM +, Brian Somers wrote:

> Any comments Poul ?  Is this anything to do with the recent command 
> line buffering ?

I guess it goes with the "stop ps showing the environment" changes.
If you remove one it makes sense to remove the other.

David.

phk 1999/11/21 11:03:21 PST

  Log:
  Introduce the new function
  p_trespass(struct proc *p1, struct proc *p2)
  which returns zero or an errno depending on the legality of p1 trespassing
  on p2.
  
  Replace kern_sig.c:CANSIGNAL() with call to p_trespass() and one
  extra signal related check.
  
  Replace procfs.h:CHECKIO() macros with calls to p_trespass().
  
  Only show command lines to process which can trespass on the target
  process.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Brian Somers writes:
>> In the last episode (Nov 23), Brian Somers said:
>> > $ ps jtva
>> > USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
>> > root   222 1   222 9dac400 Is+   va0:00.01  (getty)
>> > $ sudo ps jtva
>> > USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
>> > root   222 1   222 9dac400 Is+   va0:00.01 /usr/libexec/getty Pc tt
>> > $ head -1 /etc/motd
>> > FreeBSD 4.0-CURRENT (HAK) #9: Mon Nov 22 01:09:55 GMT 1999
>> > 
>> > This looks a bit wrong
>> 
>> Now that does look weird.  After a bit more investigation, it looks
>> like you can only get the full commandline of your own processes.  Root
>> can see all commandlines.

>Any comments Poul ?  Is this anything to do with the recent command 
>line buffering ?

Yes, I changed it to this behaviour at warners asking (I think he had
the security-meister hard-hat on at the time).

I'm personally leaning towards the opinion that the argv is public
property and should be visible, but then again, I can see the point
in hiding it in some circumstances.

I'll stick a sysctl in there which defaults to the "open" position
and people who need to hide it can set it to "close" to do so.

Will this satisfy everybody ?

Warner ?

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Andrey A. Chernov]

On Tue, Nov 23, 1999 at 05:11:37PM -0600, Dan Nelson wrote:
> Now that does look weird.  After a bit more investigation, it looks
> like you can only get the full commandline of your own processes.  Root
> can see all commandlines.

Yes, I can confirm it too on recently rebuilded -current.
Looks like access to this info becomes too restrictive. Something bad
in the kernel, not in kvm library.

-- 
Andrey A. Chernov
http://nagual.pp.ru/~ache/
MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Brian Somers]

> In the last episode (Nov 23), Brian Somers said:
> > $ ps jtva
> > USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
> > root   222 1   222 9dac400 Is+   va0:00.01  (getty)
> > $ sudo ps jtva
> > USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
> > root   222 1   222 9dac400 Is+   va0:00.01 /usr/libexec/getty Pc tt
> > $ head -1 /etc/motd
> > FreeBSD 4.0-CURRENT (HAK) #9: Mon Nov 22 01:09:55 GMT 1999
> > 
> > This looks a bit wrong
> 
> Now that does look weird.  After a bit more investigation, it looks
> like you can only get the full commandline of your own processes.  Root
> can see all commandlines.

Any comments Poul ?  Is this anything to do with the recent command 
line buffering ?

> -- 
>   Dan Nelson
>   [EMAIL PROTECTED]
> 

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Dan Nelson]

In the last episode (Nov 23), Brian Somers said:
> $ ps jtva
> USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
> root   222 1   222 9dac400 Is+   va0:00.01  (getty)
> $ sudo ps jtva
> USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
> root   222 1   222 9dac400 Is+   va0:00.01 /usr/libexec/getty Pc tt
> $ head -1 /etc/motd
> FreeBSD 4.0-CURRENT (HAK) #9: Mon Nov 22 01:09:55 GMT 1999
> 
> This looks a bit wrong

Now that does look weird.  After a bit more investigation, it looks
like you can only get the full commandline of your own processes.  Root
can see all commandlines.

-- 
Dan Nelson
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Ben Smithurst]

Dan Nelson wrote:

> In the last episode (Nov 23), Forrest Aldrich said:
>> Why does ps not show the full path on 4.0 as in 3.3? (for non-root
>> users)
>> 
>> 4.0> ps -ax
>> 
>>134  v2  Is+0:00.00  (getty)
>>135  v3  Is+0:00.00  (getty)
>>136  v4  Is+0:00.00  (getty)
>>137  v5  Is+0:00.00  (getty)
>> 
>> 3.3> ps -ax
>> 
>>312  v0  Is+0:00.01 /usr/libexec/getty Pc ttyv0
>>313  v1  Is+0:00.01 /usr/libexec/getty Pc ttyv1
>>314  v2  Is+0:00.01 /usr/libexec/getty Pc ttyv2
> 
> That just means that on your 4.0 box, the gettys have been swapped out. 

Wouldn't there be a difference in the STAT columns on each system if
that were the case? (A 'W' according to ps(1) for the swapped out
processes.)

-- 
Ben Smithurst| PGP: 0x99392F7D
[EMAIL PROTECTED] |   key available from keyservers and
 |   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Brian Somers]

> In the last episode (Nov 23), Forrest Aldrich said:
> > Why does ps not show the full path on 4.0 as in 3.3? (for non-root
> > users)
> > 
> > 4.0> ps -ax
> > 
> >134  v2  Is+0:00.00  (getty)
> >135  v3  Is+0:00.00  (getty)
> >136  v4  Is+0:00.00  (getty)
> >137  v5  Is+0:00.00  (getty)
> > 
> > 3.3> ps -ax
> > 
> >312  v0  Is+0:00.01 /usr/libexec/getty Pc ttyv0
> >313  v1  Is+0:00.01 /usr/libexec/getty Pc ttyv1
> >314  v2  Is+0:00.01 /usr/libexec/getty Pc ttyv2
> 
> That just means that on your 4.0 box, the gettys have been swapped out. 
> ps will not swap the process back in just to get the processname unless
> you give it the -f flag (and are root).

$ ps jtva
USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
root   222 1   222 9dac400 Is+   va0:00.01  (getty)
$ ps fjtva
USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
root   222 1   222 9dac400 Is+   va0:00.01  (getty)
$ sudo ps jtva
USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
root   222 1   222 9dac400 Is+   va0:00.01 /usr/libexec/getty Pc tt
$ sudo ps fjtva
USER   PID  PPID  PGID   SESS JOBC STAT  TT   TIME COMMAND
root   222 1   222 9dac400 Is+   va0:00.01 /usr/libexec/getty Pc tt
$ head -1 /etc/motd
FreeBSD 4.0-CURRENT (HAK) #9: Mon Nov 22 01:09:55 GMT 1999

This looks a bit wrong

> -- 
>   Dan Nelson
>   [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Wilko Bulte]

As Forrest Aldrich wrote ...
> 
> Why does ps not show the full path on 4.0 as in 3.3?
> (for non-root users)
> 
> ie:
> 
> 4.0> ps -ax
> 
>134  v2  Is+0:00.00  (getty)
>135  v3  Is+0:00.00  (getty)
>136  v4  Is+0:00.00  (getty)
>137  v5  Is+0:00.00  (getty)

() means swapped out processes IIRC.

-- 
|   / o / /  _  Arnhem, The Netherlands   - Powered by FreeBSD -
|/|/ / / /( (_) Bulte   WWW : http://www.tcja.nl  http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Dan Nelson]

In the last episode (Nov 23), Forrest Aldrich said:
> Why does ps not show the full path on 4.0 as in 3.3? (for non-root
> users)
> 
> 4.0> ps -ax
> 
>134  v2  Is+0:00.00  (getty)
>135  v3  Is+0:00.00  (getty)
>136  v4  Is+0:00.00  (getty)
>137  v5  Is+0:00.00  (getty)
> 
> 3.3> ps -ax
> 
>312  v0  Is+0:00.01 /usr/libexec/getty Pc ttyv0
>313  v1  Is+0:00.01 /usr/libexec/getty Pc ttyv1
>314  v2  Is+0:00.01 /usr/libexec/getty Pc ttyv2

That just means that on your 4.0 box, the gettys have been swapped out. 
ps will not swap the process back in just to get the processname unless
you give it the -f flag (and are root).

-- 
Dan Nelson
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ps on 4.0-current

[Greg Lehey]

On Tuesday, 23 November 1999 at 13:15:58 -0500, Forrest Aldrich wrote:
> 
> Why does ps not show the full path on 4.0 as in 3.3?
> (for non-root users)
> 
> ie:
> 
> 4.0> ps -ax
> 
>134  v2  Is+0:00.00  (getty)
>135  v3  Is+0:00.00  (getty)
>136  v4  Is+0:00.00  (getty)
>137  v5  Is+0:00.00  (getty)

Have you rebuilt world?  It looks fine here with a kernel supped this
morning and built 20 minutes ago.

Greg
-- 
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ps on 4.0-current

[Forrest Aldrich]

Why does ps not show the full path on 4.0 as in 3.3?
(for non-root users)

ie:

4.0> ps -ax

   134  v2  Is+0:00.00  (getty)
   135  v3  Is+0:00.00  (getty)
   136  v4  Is+0:00.00  (getty)
   137  v5  Is+0:00.00  (getty)

3.3> ps -ax

   312  v0  Is+0:00.01 /usr/libexec/getty Pc ttyv0
   313  v1  Is+0:00.01 /usr/libexec/getty Pc ttyv1
   314  v2  Is+0:00.01 /usr/libexec/getty Pc ttyv2



??


_F





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message