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 ag
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
==
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 arg
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
> : ha
> > 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 somet
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
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
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
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 us
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
< 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? Remem
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
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 re
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-maste
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
inadvertantl
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 [E
:> > 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 ACCEPT
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
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, b
> 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 th
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 th
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
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 wor
> "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
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
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
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 l
> 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 2
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
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)
>>
> 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
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)
() mea
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 (get
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)
>
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
35 matches
Mail list logo
