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 mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 excluded as well. FWIW, I'd be against removing or restricting -e at all. Programs that put sensitive data into environment variables (or expect the user to do that) are just _broken_. Removing or restricting the -e option encourages such brokenness. Just my 0.02 Euro. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 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. FWIW, I'd be against removing or restricting -e at all. Programs that put sensitive data into environment variables (or expect the user to do that) are just _broken_. Removing or restricting the -e option encourages such brokenness. Just my 0.02 Euro. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 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. FWIW, I'd be against removing or restricting -e at all. Programs that put sensitive data into environment variables (or expect the user to do that) are just _broken_. Removing or restricting the -e option encourages such brokenness. Just my 0.02 Euro. since the environment is supposed to be part of the address space it is ssupposed to be private.. But it is not, and programmers should be aware of it. On all platforms on which I regularly work (*BSD, Solaris, DEC UNIX a.k.a Tru64) the environments of all processes are public. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 instead of removing it entirely. That would remove the security concern, but still retain the function for root. Removing the function for root is useless from a security point of view, as anybody with root access can simply compile an alternative version of ps(1) with -e back in it. Cheers. -- ++ . | John Saunders - mailto:[EMAIL PROTECTED] (EMail) | ,--_|\|- http://www.nlc.net.au/ (WWW) | / Oz \ |- 02-9489-4932 or 04-1822-3814 (Phone) | \_,--\_/ | NORTHLINK COMMUNICATIONS P/L - Supplying a professional, | v| and above all friendly, internet connection service. | ++ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 will only allow inspection of the environment of processes for which the owner of the ps process has sufficient priveledge. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 root at least... Exactly. In a perfect world, the -e option will only allow inspection of the environment of processes for which the owner of the ps process has sufficient priveledge. Yes that makes sense, because if all comes to all they could attach a debugger and find it that way anyway. -- 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: 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 the command line args - both might leak private data. Anyone writing programs which don't want to leak data should know not to put it on the command line or in the environment. If the 'e' option is removed from FreeBSD it doesn't make the life of anyone writing programs any easier 'cos other versions of Unix will continue to expose the environment variables. Also, setting environment variables is a simple way of exporting data from a program. For example you can set variables in hosts.allow saying where the connection the created the process came from and then examine this with ps -e later. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 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 unreliable and just annoying. The benefits are fairly minimal, and I don't believe justify the cost incurred. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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). 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. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 unreliable and just annoying. : :The benefits are fairly minimal, and I don't believe justify the cost :incurred. If it weren't for 'setproctitle()' I would agree with you. But since setproctitle() exists we have a serious mess on our hands. Personally I would prefer to see it cleaned up as follows: * place a copy of the initial arguments in the struct proc as well as the uarea. * have the sysctl that limits the buffer size within the struct proc to something reasonable (e.g. 1K) but don't bother making 'ps' fall back to the uarea. Allow a value of '0' indicating 'unlimited' (i.e. really means ARGS_MAX). * setproctitle() messes with the struct proc only * ps, top, et all use the struct proc only And, also, we need to get rid of the 'e' option to ps entirely. It's a major security hole. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 sensitive in the command line or the environment. When there's any risk, the best option is to remove 'ps' alltogether, IMHO. -- Pierre Beyssac[EMAIL PROTECTED] [EMAIL PROTECTED] BSD : il y a moins bien, mais c'est coté en bourse Free domains: http://www.eu.org/ or mail [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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's common knowledge under Unix that you shouldn't put anything sensitive in the command line or the environment. When there's any risk, the best option is to remove 'ps' alltogether, IMHO. Sorry for jumping in here... When looking for "old" processes on shell boxes, I often find myself using ps -e and grepping for the DISPLAY variable, in order to find out if it's an abandoned local process, or if it was redirected to some remote host. That's what I'd need ps -e for. or is there another, possibly easier way to accomplish that? Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 unreliable and just annoying. : :The benefits are fairly minimal, and I don't believe justify the cost :incurred. If it weren't for 'setproctitle()' I would agree with you. But since setproctitle() exists we have a serious mess on our hands. Personally I would prefer to see it cleaned up as follows: * place a copy of the initial arguments in the struct proc as well as the uarea. * have the sysctl that limits the buffer size within the struct proc to something reasonable (e.g. 1K) but don't bother making 'ps' fall back to the uarea. Allow a value of '0' indicating 'unlimited' (i.e. really means ARGS_MAX). * setproctitle() messes with the struct proc only * ps, top, et all use the struct proc only 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. I don't agree with putting the command args in the proc struct, however, for the reason that Sean mentioned above. 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 Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 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 passed to the program, and thus non deterministic. Since we have setproctitle(), we can depreciate the argv junk. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 passed to the program, and thus non deterministic. Since we have setproctitle(), we can depreciate the argv junk. I'm not running current at the moment so the following may be a dumb question. Did something happen such that argv wouldn't work anymore? I use a program which sets arguments via argv, and it seems to be working fine under 3.2-release. And going for dumb question #2, how does ps find the argv now? One of the earlier messages in this thread said something about it "rummaging around" on the other processes' space. Could the proc struc contain a pointer to the exact location in the other processes' space, thus making it quicker for ps to find it? --- 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: 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 process memory. 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 unreliable and just annoying. The benefits are fairly minimal, and I don't believe justify the cost incurred. That's fine, you can disable it by setting the sysctl. -- 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: 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 process memory. : :This patch: :Speeds up ps(1). 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. Hmm, well, I like to have it around for root at least... -- 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: 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 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). Let me clarify some details about my patch: The args are not in struct proc, they hung in a separate data structure off struct proc, so the size increase of struct proc is one pointer. It can be disabled completely (apart from the pointer) with the provided sysctl. The data structure is shared across fork, until exec. Caching the argument list saves us a vnode and a procfs inode per running process (/proc/*/mem). So far I have not been able to see a net increase in memory usage. Please look at kvm_getargv(), procfs_mem.c and consider carefully the case where two processes on a SMP system, both "ps -ax", are at the same time examining one of these two processes memory to get the argv. -- 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: PATCH for testing
Alex Zepeda wrote: On Fri, 19 Nov 1999, Warner Losh wrote: In message Pine.BSF.4.10.9911182311590.338-10@localhost 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? *grin* I can't believe this is still being discussed! This was "fixed" two days ago so that 'ps -e' by a normal user can only see the environment of processes that they own.. No matter whether they use -a, -U, etc. Root can (of course) still see the environment of all processes. -stable is a different matter. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
In message Pine.BSF.4.10.9911172341110.397-10@localhost 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 of the message
Re: PATCH for testing
: :In message Pine.BSF.4.10.9911172341110.397-10@localhost 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 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. The danger is that the option exists in the first place. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 then it already is. The danger is that the option exists in : the first place. I'm not for removing -e. It is useful to root for debugging. If ps can get this info from procfs, procfs could effectively enforce this restriction. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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. The danger is that the option exists in the first place. I both do and do not want it to be removed. The code _does not_ need to be more complex, as procfs already implements the correct restrictions. (Simply dropping the SGID bit off of ps(1), and teaching it to use procfs only, will do it; dropping the SGID bit, and having it use /proc/pid/mem instead of /dev/kmem, will do the same thing. I believe; I don't know ps well enough to figure this all out yet, but that was certainly one of my goals when I wrote the bloody thing.) P.S. You see that Reply-To: line in the header? It's there for a reason. If you must override it, don't send it to both me and the list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 more complex then it already is. The danger is that the option exists in the first place. I both do and do not want it to be removed. The code _does not_ need to be more complex, as procfs already implements the correct restrictions. (Simply dropping the SGID bit off of ps(1), and teaching it to use procfs only, will do it; dropping the SGID bit, and having it use /proc/pid/mem instead of /dev/kmem, will do the same thing. I believe; I don't know ps well enough to figure this all out yet, but that was certainly one of my goals when I wrote the bloody thing.) Well, it's already done. It (ps) hasn't used /dev/kmem for a Very Long Time. The only thing it used procfs for was the argv, envp and getting p_stats from the user struct. The code to get p_stats via procfs has been directly implicated in causing panics and crashes, so it (ps) gets it with the sysctl it uses to get the rest of the information. The sole user of / proc in ps now is to get the envp, and ps is no longer setgid. ps now depends on /proc's permissions enforcement to allow access to /proc/*/mem for getting envp for processes that the user owns. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
On Thu, 18 Nov 1999, Warner Losh wrote: In message Pine.BSF.4.10.9911172341110.397-10@localhost 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 owned by that user, no? - alex 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 complex then it already is. The danger is that the option exists in the first place. Though I respect your statement about code complexity I'm not for removing the option, which has been available to the ps command for such a long time and definitively is a useful debugging tool (for root !). This would create a major difference to the other BSD's which is not easily understandable. "ps -e" and "ps -e -U" is useful for debugging purposes, so it should simply be restricted to root as it has been done for putting a network device into promiscous mode or other things. 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 ;-) Security is a good reason. But simply removing it without restricting it is in my opineon not a good style. Another alternative to restricting it to root would be, to combine it with the security level, that we can configure in rc.conf. But that's only an idea, I personally don't like magic things to happen, only because I raised a security level by one. Andreas /// -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
In message Pine.BSF.4.10.9911182311590.338-10@localhost 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
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 far too radical. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
On Fri, 19 Nov 1999, Warner Losh wrote: In message Pine.BSF.4.10.9911182311590.338-10@localhost 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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
In message Pine.BSF.4.10.9911182331120.338-10@localhost 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 current set of access policies may be less than idea, it doesn't militate for their complete removal. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
On Fri, 19 Nov 1999, Warner Losh wrote: In message Pine.BSF.4.10.9911182331120.338-10@localhost 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 current set of access policies may be less than idea, it doesn't militate for their complete removal. Erk. That came out wrong. I meant removal for non root or perhaps non gid wheel? or somesuch. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
In message Pine.BSF.4.10.9911182338520.338-10@localhost 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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 entirely. Then other utility would have to go as well (tcpdump, ...). -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 'e' option. There is no need to get rid of it entirely. Then other utility would have to go as well (tcpdump, ...). Or perhaps restricting -U to root only? Since -e w/out -U isn't harmful, no? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
