sparc64 patch for testing.

to keep the sparc 64 pmap up with the others.. I had a look at a couple of thread related points. Here's a possible diff (1 bug found I think) any sparc64 people care to comment? (cat-n-pasted patch) The last addition is I think needed to not leak KV space. The first changes are because the co

Re: PATCH for testing

Julian Elischer wrote in list.freebsd-current: > On Wed, 17 Nov 1999, Oliver Fromme wrote: > > Adam Wight wrote in list.freebsd-current: > > > x I like the -e option when I'm root and trying to debug things. I > > > x think that peter's fix seems to be ideal. You can find out about your

Re: PATCH for testing

since the environment is supposed to be part of the address space it is ssupposed to be private.. On Wed, 17 Nov 1999, Oliver Fromme wrote: > Adam Wight wrote in list.freebsd-current: > > x I like the -e option when I'm root and trying to debug things. I > > x think that peter's fix seems t

Re: PATCH for testing

Adam Wight wrote in list.freebsd-current: > x I like the -e option when I'm root and trying to debug things. I > x think that peter's fix seems to be ideal. You can find out about your > x own uid, but no one else's unless you are root. > > I agree, but anything that runs suid has to be

Re: PATCH for testing

x I like the -e option when I'm root and trying to debug things. I x think that peter's fix seems to be ideal. You can find out about your x own uid, but no one else's unless you are root. I agree, but anything that runs suid has to be excluded as well. -Adam Wight To Unsubscribe: send ma

Re: PATCH for testing

In message <[EMAIL PROTECTED]> Matthew Dillon writes: : Why don't we get rid of the 'e' option to ps while we are at it : considering how much of a security hole it is. I've never liked the : 'e' option. I like the -e option when I'm root and trying to debug things. I think that pe

Re: PATCH for testing

Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Sheldon Hearn writes: > > > > > >On Tue, 16 Nov 1999 07:19:52 +0100, Poul-Henning Kamp wrote: > > > >> >Why don't we get rid of the 'e' option to ps while we are at it > >> >considering how much of a security hole it is. > >> > >

Re: PATCH for testing

On Mon, Nov 15, 1999 at 02:18:24PM -0800, Matthew Dillon wrote: > Why don't we get rid of the 'e' option to ps while we are at it > considering how much of a security hole it is. I've never liked the > 'e' option. If we get rid of the 'e' option we should also get rid of showing th

Re: PATCH for testing

In message <[EMAIL PROTECTED]>, Sheldon Hearn writes: > > >On Tue, 16 Nov 1999 07:19:52 +0100, Poul-Henning Kamp wrote: > >> >Why don't we get rid of the 'e' option to ps while we are at it >> >considering how much of a security hole it is. >> >> Hmm, well, I like to have it around for r

Re: PATCH for testing

On Tue, 16 Nov 1999 07:19:52 +0100, Poul-Henning Kamp wrote: > >Why don't we get rid of the 'e' option to ps while we are at it > >considering how much of a security hole it is. > > Hmm, well, I like to have it around for root at least... Exactly. In a perfect world, the -e option w

Re: PATCH for testing

> >And, also, we need to get rid of the 'e' option to ps entirely. It's a > >major security hole. > >I agree that we need to get rid of 'e' and any other options that allow > reading another process's environment. How about protecting the -e option by a test for setuid() == 0 instea

Re: PATCH for testing

In message <[EMAIL PROTECTED]>, David Greenman writes: > I agree that we need to get rid of 'e' and any other options that allow >reading another process's environment. I don't agree with putting the command >args in the proc struct, however, for the reason that Sean mentioned above. >In my opi

Re: PATCH for testing

In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >:http://phk.freebsd.dk/misc/p_args.patch >: >:The p_args.patch patch implements a cache of the commandline arguments >:in the process structure and makes ps(1) pick it up from there with >:sysctl rather than by groping around in the target pr

Re: PATCH for testing

In message <[EMAIL PROTECTED]>, Sean Eric Fagan writes: >In article <[EMAIL PROTECTED]> you write: >>The p_args.patch patch implements a cache of the commandline arguments >>in the process structure and makes ps(1) pick it up from there with >>sysctl rather than by groping around in the target pro

Re: PATCH for testing

At 6:22 PM -0800 11/15/99, Matthew Dillon wrote: >Well, I think there is an issue in the proc struct bloat but I disagree >strongly about modifying argv - any worthwhile code uses setproctitle() >now simply because the argv space is highly dependant on the number of >arguments pass

Re: PATCH for testing

:In my opinion, doing so majorly bloats the proc struct for no good reason and :also introduces gratuitous incompatibilities for utilities that want to modify :their argv[*] and expect the modifications to show up in ps(1). : :-DG : :David Greenman Well, I think there is an issue in the proc

Re: PATCH for testing

>:I don't think this should go in at all. >: >:It increases the size of the proc structure (thereby affecting _all_ >:processes) gratuitously. While I'm generally in favour of having the process >:arguments kept around, the "BSD way" has been to only examine them in user >:memory, despite that be

Re: PATCH for testing

Pierre Beyssac wrote in list.freebsd-current: > On Mon, Nov 15, 1999 at 02:27:10PM -0800, Matthew Dillon wrote: > > And, also, we need to get rid of the 'e' option to ps entirely. It's a > > major security hole. > > Not more so than option 'u', or even 'a', if you ask me. > > It'

Re: PATCH for testing

On Mon, Nov 15, 1999 at 02:27:10PM -0800, Matthew Dillon wrote: > And, also, we need to get rid of the 'e' option to ps entirely. It's a > major security hole. Not more so than option 'u', or even 'a', if you ask me. It's common knowledge under Unix that you shouldn't put anything sensi

Re: PATCH for testing

:I don't think this should go in at all. : :It increases the size of the proc structure (thereby affecting _all_ :processes) gratuitously. While I'm generally in favour of having the process :arguments kept around, the "BSD way" has been to only examine them in user :memory, despite that being un

Re: PATCH for testing

:http://phk.freebsd.dk/misc/p_args.patch : :The p_args.patch patch implements a cache of the commandline arguments :in the process structure and makes ps(1) pick it up from there with :sysctl rather than by groping around in the target process memory. : :This patch: :Speeds up ps(1).

Re: PATCH for testing

In article <[EMAIL PROTECTED]> you write: >The p_args.patch patch implements a cache of the commandline arguments >in the process structure and makes ps(1) pick it up from there with >sysctl rather than by groping around in the target process memory. I don't think this should go in at all. It in

PATCH for testing

http://phk.freebsd.dk/misc/p_args.patch The p_args.patch patch implements a cache of the commandline arguments in the process structure and makes ps(1) pick it up from there with sysctl rather than by groping around in the target process memory. This patch: Speeds up ps(1). Red

Re: PATCH for testing

Alex Zepeda wrote: > On Fri, 19 Nov 1999, Warner Losh wrote: > > > In message Alex Zepeda w rites: > > : ps -e w/out -U only shows variables for processes owned by that user, no? > > > > ps -ea. > > Then perhaps -a and -U should be disabled

Re: PATCH for testing

In message Alex Zepeda writes: : Erk. That came out wrong. I meant removal for non root or : perhaps non gid wheel? or somesuch. Actually, you wanna do access control like procfs does (will do?) for its cmdline file. Warner To Unsubscribe:

Re: PATCH for testing

On Fri, 19 Nov 1999, Warner Losh wrote: > In message Alex Zepeda writes: > : Then perhaps -a and -U should be disabled? *grin* > > No. -e, -a, -U are all use for the sysadmin. They can provide > sensitive information, so should have sensible

Re: PATCH for testing

In message Alex Zepeda writes: : Then perhaps -a and -U should be disabled? *grin* No. -e, -a, -U are all use for the sysadmin. They can provide sensitive information, so should have sensible access policies placed upon their use. While the c

Re: PATCH for testing

On Fri, 19 Nov 1999, Warner Losh wrote: > In message Alex Zepeda writes: > : ps -e w/out -U only shows variables for processes owned by that user, no? > > ps -ea. Then perhaps -a and -U should be disabled? *grin* - alex To Unsubscribe: sen

Re: PATCH for testing

In message <[EMAIL PROTECTED]> Andreas Klemm writes: : By simply removing it (without thinking about alternatives) I : think FreeBSD looses some points ... I thought we were the team : that doesn't do radical changes without a good reason ;-) That's why I'm not in favor of removing it. That's fa

Re: PATCH for testing

In message Alex Zepeda writes: : ps -e w/out -U only shows variables for processes owned by that user, no? ps -ea. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: PATCH for testing

On Thu, Nov 18, 1999 at 05:04:20PM -0800, Matthew Dillon wrote: > I am all for removing -e, but I don't really like the idea of making > it optional nor do I like the idea of trying to maintain the capability > for the user's own processes - that simply makes the code even more > c

Re: PATCH for testing

On Thu, 18 Nov 1999, Warner Losh wrote: > In message Alex Zepeda writes: > : Or perhaps restricting -U to root only? Since -e w/out -U isn't harmful, > : no? > > -e w/o -U is still harmful. ps -e w/out -U only shows variables for processes own

Re: PATCH for testing

Sean Eric Fagan wrote: > In article <[EMAIL PROTECTED] m> you write: > >I am all for removing -e, but I don't really like the idea of making > >it optional nor do I like the idea of trying to maintain the capability > >for the user's own processes - that simply makes the code even

Re: PATCH for testing

In article <[EMAIL PROTECTED]> you write: >I am all for removing -e, but I don't really like the idea of making >it optional nor do I like the idea of trying to maintain the capability >for the user's own processes - that simply makes the code even more >complex then it already is

Re: PATCH for testing

In message <[EMAIL PROTECTED]> Matthew Dillon writes: : I am all for removing -e, but I don't really like the idea of making : it optional nor do I like the idea of trying to maintain the capability : for the user's own processes - that simply makes the code even more : complex the

Re: PATCH for testing

: :In message Alex Zepeda writes: :: Or perhaps restricting -U to root only? Since -e w/out -U isn't harmful, :: no? : :-e w/o -U is still harmful. : :Warner I am all for removing -e, but I don't really like the idea of making it optiona

Re: PATCH for testing

In message Alex Zepeda writes: : Or perhaps restricting -U to root only? Since -e w/out -U isn't harmful, : no? -e w/o -U is still harmful. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body o

Re: PATCH for testing

On Thu, 18 Nov 1999, Andreas Klemm wrote: > On Mon, Nov 15, 1999 at 05:44:12PM -0800, David Greenman wrote: > >I agree that we need to get rid of 'e' and any other options that allow > > reading another process's environment. > > I think it would be sufficient, to allow only root to use the

Re: PATCH for testing

On Mon, Nov 15, 1999 at 05:44:12PM -0800, David Greenman wrote: >I agree that we need to get rid of 'e' and any other options that allow > reading another process's environment. I think it would be sufficient, to allow only root to use the 'e' option. There is no need to get rid of it entirel