her@compel.UUCP (Helge Egelund Rasmussen) (04/17/91)
It is possible to give Oracle programs the username/password on the
command line, ie :
$ sqlplus scott/tiger
This is all very nice, BUT when another user execute 'ps -ef' he/she
can see the password!
Is it possible to hide the arguments, so that they won't show up in
the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)??
I know that Oracle will ask for the username & password if these aren't given
as arguments, but I would prefer giving them as arguments.
Btw. I'm using SysV3 (Interactive Unix).
Helge
---
Helge E. Rasmussen . PHONE + 45 36 72 33 00 . E-mail: her@compel.dk
Compel A/S . FAX + 45 36 72 43 00 .
Copenhagen, Denmarktoma@swsrv1.cirr.com (Tom Armistead) (04/18/91)
In article <1414@compel.UUCP> her@compel.UUCP (Helge Egelund Rasmussen) writes: >It is possible to give Oracle programs the username/password on the >command line, ie : > $ sqlplus scott/tiger > >This is all very nice, BUT when another user execute 'ps -ef' he/she >can see the password! > >Is it possible to hide the arguments, so that they won't show up in >the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)?? > >I know that Oracle will ask for the username & password if these aren't given >as arguments, but I would prefer giving them as arguments. > >Btw. I'm using SysV3 (Interactive Unix). > >Helge >--- >Helge E. Rasmussen . PHONE + 45 36 72 33 00 . E-mail: her@compel.dk >Compel A/S . FAX + 45 36 72 43 00 . >Copenhagen, Denmark I THINK this is impossible - but I'm not a kernel type - so don't quote me on that. If you only problem is with Oracle and SQL*Plus, you can set up Oracle accounts so that no password is entered on the command line. Oracle stuff after this line, press 'n' to skip: In Oracle, you can add accounts so that the user only enters '/' on the command line, this will be accepted as username and password. If an Oracle account of the name 'OPS$unix_user_name' exists where unix_user_name is equal to your account name, you will connected to that account with '/' and no password is required. ex. SQL> GRANT CONNECT,RESOURCE TO OPS$TOMA IDENTIFIED BY SADKJSALJK; The password is basically just junk to keep unauthorized people from using the account. Now, I log into unix as toma and run sqlplus like this: $ sqlplus / Hope this helps... Tom -- Tom Armistead - Software Services - 2918 Dukeswood Dr. - Garland, Tx 75040 =========================================================================== toma@swsrv1.cirr.com {egsner,letni,ozdaltx,void}!swsrv1!toma
bonnett@seismo.CSS.GOV (H. David Bonnett) (04/19/91)
In article <1991Apr17.222700.4586@swsrv1.cirr.com>, toma@swsrv1.cirr.com (Tom Armistead) writes: |> In article <1414@compel.UUCP> her@compel.UUCP (Helge Egelund Rasmussen) writes: |> >It is possible to give Oracle programs the username/password on the |> >command line, ie : |> > $ sqlplus scott/tiger |> > |> >This is all very nice, BUT when another user execute 'ps -ef' he/she |> >can see the password! |> > |> >Is it possible to hide the arguments, so that they won't show up in |> >the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)?? |> > |> >I know that Oracle will ask for the username & password if these aren't given |> >as arguments, but I would prefer giving them as arguments. |> > |> >Btw. I'm using SysV3 (Interactive Unix). You don't say what version of Oracle you are running, but this is handled in the sqlplus shipped with 6.0.30: When I connect to the database through sqlplus as follows: {trym:~ 161}=> sqlplus scott/tiger@t:HOST:oracle SQL*Plus: Version 3.0.8.1.1 - Production on Thu Apr 18 15:57:07 1991 Copyright (c) Oracle Corporation 1979, 1989. All rights reserved. ps e shows: 684 p1 S 0:00 sqlplus DISPLAY=trym:0.0 (etc) No magic is needed at all. -- -dave bonnett- Center for Seismic Studies; Arlington, VA bonnett@seismo.css.gov : All standard disclaimers apply.
her@compel.UUCP (Helge Egelund Rasmussen) (04/19/91)
>>Is it possible to hide the arguments, so that they won't show up in >>the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)?? I received a lot of replies for this question (Thanx to all!!), and the main result (until now) is that it isn't really possible (at least not in the general case). The best ones so far is: 1: exec the program with a very long argument ie. "<fullpath>//////////////////////////sqlplus scott/tiger" The idea of this is presumably, that ps only will show the first n characters of the argument list. 2: Modify the argv[] list in the exec'ed program after startup. This will ofcourse be a problem with sqlplus, but might work with 'runform' (using a user exit) or "home made" applications. My questions are now: Will 1 above work? Even if ps won't show the arguments, it might be possible to write a program which can read the argument list from memory. Is this possible? If it is, then this method isn't really safe. The problem with method 2 above is, as far as I can see, that it wouldn't be really safe because of race conditions. Ie. sometimes a user might have time to execute a PS in the time after the exec, and before the application have had time to destroy the argv structure. Is this correct? Helge --- Helge E. Rasmussen . PHONE + 45 36 72 33 00 . E-mail: her@compel.dk Compel A/S . FAX + 45 36 72 43 00 . Copenhagen, Denmark
subbarao@phoenix.Princeton.EDU (Kartik Subbarao) (04/19/91)
In article <1429@compel.UUCP> her@compel.UUCP (Helge Egelund Rasmussen) writes: >>>Is it possible to hide the arguments, so that they won't show up in >>>the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)?? > > 2: Modify the argv[] list in the exec'ed program after startup. > This will ofcourse be a problem with sqlplus, but might work with > 'runform' (using a user exit) or "home made" applications. > >My questions are now: > Will 1 above work? Even if ps won't show the arguments, it might be possible > to write a program which can read the argument list from memory. Is this > possible? If it is, then this method isn't really safe. No, the "ww" argument to ps will cause ps to not stop once it has reached the max number of columns. You may want to pipe the output through fold. Since only programs with access to /dev/kmem can get to where the argument vector's stored, if ps didnt have such an option, the option of making a big argv0 might be a viable solution. But, ps does have such an option. > The problem with method 2 above is, as far as I can see, that it wouldn't > be really safe because of race conditions. Ie. sometimes a user might have > time to execute a PS in the time after the exec, and before the application > have had time to destroy the argv structure. Is this correct? Yes. This "problem" is documented in the man page for crypt(1). Crypt also clobbers its argv array once it's read it in, but its possible to do a ps just before it manages to do this and find it out. -Kartik -- internet# rm `df | tail +2 | awk '{ printf "%s/quotas\n",$6}'` subbarao@phoenix.Princeton.EDU -| Internet kartik@silvertone.Princeton.EDU (NeXT mail) SUBBARAO@PUCC.BITNET - Bitnet
xtdn@levels.sait.edu.au (04/19/91)
her@compel.UUCP (Helge Egelund Rasmussen) writes: > It is possible to give Oracle programs the username/password on the > command line, ie : ... > Is it possible to hide the arguments, so that they won't show up in > the 'ps' output What you want to do is not good. Sure you might be able to write something which accepts command line arguments, hides them and then calls Oracle; but there will always be a window of time between when your program is started and when it zaps its arguments. During that window, the arguments will be available for all* to see. I think you should re-evaluate your need to use command arguments. * Mind you, systems, such as SCO Unix, which have C2 security, don't show processes belonging to other users (unless you have the appropriate permission). Not that I'm advocating a switch to C2 Unix. David Newall, who no longer works Phone: +61 8 344 2008 for SA Institute of Technology E-mail: xtdn@lux.sait.edu.au "Life is uncertain: Eat dessert first"
clewis@ferret.ocunix.on.ca (Chris Lewis) (04/20/91)
In article <1414@compel.UUCP> her@compel.UUCP (Helge Egelund Rasmussen) writes: >It is possible to give Oracle programs the username/password on the >command line, ie : > $ sqlplus scott/tiger >This is all very nice, BUT when another user execute 'ps -ef' he/she >can see the password! >Is it possible to hide the arguments, so that they won't show up in >the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)?? I don't know how bullet proof this is, or how portable, but on many versions of UNIX you can overwrite the character strings that the argv[] array points to. Ie: main(...) { char *p; /* parse arguments */ for (i = 0; i < argc; i++) for (p = argv[i]; *p; p++) *p++ = '\0'; You probably only have to zero the first byte in the argv[i] strings. We used to do this to rename/hide executing game programs at a company I used to work for. BTW: BSD 4.1 accounting wouldn't even show jobs that had a control character in their name ;-) This doesn't help directly, because you presumably don't have source to sqlplus, and this only works for the *current* process. What you could do is something like the above, but after clobbering arguments, pipe/fork/exec sqlplus, and stuff the password down the pipe, then relinquish stdin to the terminal. This, does still leave a short window tho... Frankly, if you're concerned about the password, you shouldn't do this anyways - it becomes too tempting to put passwords in shell scripts... -- Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca UUCP: uunet!mitel!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/21/91)
As quoted from <1429@compel.UUCP> by her@compel.UUCP (Helge Egelund Rasmussen): +--------------- | >>Is it possible to hide the arguments, so that they won't show up in | >>the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)?? | | I received a lot of replies for this question (Thanx to all!!), and the main | result (until now) is that it isn't really possible (at least not in the | general case). | | The best ones so far is: | 1: exec the program with a very long argument ie. | "<fullpath>//////////////////////////sqlplus scott/tiger" | | The idea of this is presumably, that ps only will show the first n | characters of the argument list. | | 2: Modify the argv[] list in the exec'ed program after startup. | This will ofcourse be a problem with sqlplus, but might work with | 'runform' (using a user exit) or "home made" applications. +--------------- Not under Interactive or any other V.3 --- rather than having programs grunge through process data space to find the arguments, the first PSARGSZ (80) characters of the command line are written to u.u_psargs with '\0' changed to a space. The first variant will work, though. Yes, programs can chase your process VM to find the argv information... but this requires root access (unless you have general read on /dev/mem and /dev/swap, in which case you've got worse security problems than this to contend with!). ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
guy@auspex.auspex.com (Guy Harris) (04/21/91)
> The problem with method 2 above is,
The problem with method 2 above is that, unless ISC UNIX is fairly
different from S5 as it comes from AT&T, "ps" doesn't *look* at the
argument list on the stack - it looks at the argument list as set up in
a string in the U area at startup, so your program can twiddle the argv
list until the cows come home and it won't affect what "ps" sees.guy@auspex.auspex.com (Guy Harris) (04/21/91)
>No, the "ww" argument to ps will cause ps to not stop once it has reached >the max number of columns. It will do so even in the ISC UNIX that the original poster said he was using? News to me; the ISC UNIX in question is S5R3-flavored, and the "ps" there may not even *have* a "ww" argument....
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/22/91)
As quoted from <7294@auspex.auspex.com> by guy@auspex.auspex.com (Guy Harris): +--------------- | >No, the "ww" argument to ps will cause ps to not stop once it has reached | >the max number of columns. | | It will do so even in the ISC UNIX that the original poster said he was | using? News to me; the ISC UNIX in question is S5R3-flavored, and the | "ps" there may not even *have* a "ww" argument.... +--------------- ...nor would it do any good, since running "ps" won't automagically increase the size of the string stashed in the ublock. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
rmtodd@servalan.uucp (Richard Todd) (04/22/91)
guy@auspex.auspex.com (Guy Harris) writes: >> The problem with method 2 above is, >The problem with method 2 above is that, unless ISC UNIX is fairly >different from S5 as it comes from AT&T, "ps" doesn't *look* at the >argument list on the stack - it looks at the argument list as set up in >a string in the U area at startup, so your program can twiddle the argv >list until the cows come home and it won't affect what "ps" sees. I must admit to not having great experience with "unadulterated" SysV, but on two SysV-derived systems I've used (A/UX and ISC Unix), ps by default only looks at the program name in the U area, but with the "f" flag will go ahead and find the program's stack and read the arg. list. Also, by default the U area "u_comm" field contains only argv[0] and none of the other argv[i]. Example (on my home system, running A/UX 2.0): --------------------------------------------------------------------------- 9 servalan ~[5:46pm] % ps -p 358 PID TTY TIME COMMAND 358 console 0:07 xdm 10 servalan ~[5:46pm] % ps -fp 358 UID PID PPID C STIME TTY TIME COMMAND root 358 129 0 15:34:03 console 0:07 /usr/bin/X11/xdm -nodaemon -udpPort 0 11 servalan ~[5:46pm] % --------------------------------------------------------------------------- It works the same way on ISC Unix. I thought this was standard System V behaviour. (I find it a tad unlikely that Apple and ISC would both add the ability to read the stack arglist to ps, and do so with the exact same flag...) -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Elvis has left Bettendorf!"
buck@sct60a.sunyct.edu (Jesse R. Buckley, Jr.) (04/23/91)
Heh, see the FAQ...
guy@auspex.auspex.com (Guy Harris) (04/23/91)
>...nor would it do any good, since running "ps" won't automagically increase >the size of the string stashed in the ublock. Well, no, it won't increase the size of the string stored there, but that doesn't mean it wouldn't necessarily do any good; the reason for "w" and "ww" in the BSD "ps" is that the BSD "ps" normally truncates the entire line at 80 columns, by chopping the command off, and "w" and "ww" increase the amount of command line printed. A quick look at the S5R3.0 "ps" indicates that if the "-l" flag is given, the string in the u area is chopped off at 35 characters rather than PSARGSZ characters, so a "w" flag might be useful there as well.
rbj@uunet.UU.NET (Root Boy Jim) (04/23/91)
In article <7293@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >The problem with method 2 above is that, unless ISC UNIX is fairly >different from S5 as it comes from AT&T, "ps" doesn't *look* at the >argument list on the stack - it looks at the argument list as set up in >a string in the U area at startup, so your program can twiddle the argv >list until the cows come home and it won't affect what "ps" sees. Around here, we run lots of sendmail, uucp, news, and a bit of ftp. We like to know what's going on, so we use a function called 'setproctitle' (from the sendmail distribution). A bit of ps: 653 ? S N 10:14 -accepting smtp connections (sendmail) 5665 ? I 3:51 -timbuk.cray.com IHAVE (in.nntpd) 6175 ? I 0:01 -wuarchive.wustl.edu IHAVE (in.nntpd) 12017 ? S N 0:00 -mmmmmmm: SLAVE R (uucico) 12819 ? R N 0:00 -M2C.M2C.ORG: HELO m2c.m2c.org (sendmail) 13841 ? I N 0:03 -SSSSSSS-SSSSSS.ARMY.MIL:lskdfj: RETR ls-ltR.Z (in.ftpd) 14575 ? I N 0:01 -AA25083 finabo.abo.fi: greeting wait (sendmail) 15843 ? S N 0:11 -harpo.ssf-sys.DHL.COM:mbisted: RETR 1.39.tar.Z.18 (in.ftpd) 18014 ? I N 1:21 -AA22570 tohu0.weizmann.ac.il: user open (sendmail) 29152 ? S 4:00 -dddddd: MASTER SENDING (uucico) We have a line in /etc/rc which says: FILLER=" "; export FILLER to give us some environment space to write over. I certainly hope that future versions of UNIX will continue to provide this information in the same fashion. At least provide a switch. Don't tell me this is non-portable; it just happens to be the oldest way. -- [rbj@uunet 1] stty sane unknown mode: sane
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/23/91)
As quoted from <1991Apr21.225044.883@servalan.uucp> by rmtodd@servalan.uucp (Richard Todd): +--------------- | I must admit to not having great experience with "unadulterated" SysV, but | on two SysV-derived systems I've used (A/UX and ISC Unix), ps by default | only looks at the program name in the U area, but with the "f" flag will | go ahead and find the program's stack and read the arg. list. Also, by +--------------- A/UX is SVR2 internally; it reads argv[] out of the program's stack. ISC --- which version? Try "grep u_psargs /usr/include/sys/user.h" and see if it finds anything --- if it does, then you have a SVR3.[12] which copies the first part of argv[] into the ublock. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 10m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
navarra@casbah.acns.nwu.edu (John 'tms' Navarra) (04/23/91)
I have been vaguely following this discussion and this might
sound simple (and of course it might not work) but if you want to hide a
process from ps (like a passwd call) how bout this:
make a /bin/ps which does the following:
exec /bin/psfiltered | grep -v passwd
then you hide psfiltered somewhere (maybe not in bin) but so it is not
readlily accessible by others and so everybody will call ps like usual but
now it can be supplied with a list not to display.
I don't know -- it's just off the top of my head.
--
From the Lab of the MaD ScIenTiST:
navarra@casbah.acns.nwu.edusubbarao@phoenix.Princeton.EDU (Kartik Subbarao) (04/23/91)
In article <1991Apr23.090439.29024@casbah.acns.nwu.edu> navarra@casbah.acns.nwu.edu (John 'tms' Navarra) writes: > > I have been vaguely following this discussion and this might > sound simple (and of course it might not work) but if you want to hide a > process from ps (like a passwd call) how bout this: > > make a /bin/ps which does the following: > > exec /bin/psfiltered | grep -v passwd Changing a system program is a really Stupid way of solving the problem. First, the person that wants to do this is not necessarily the superuser, or one with kmem access. Secondly, it's really simple to have the program read the "secret" arguments from the tty (maybe even using getpass!), rather than have to have them passed as arguments. Oh, gosh, that takes two more lines of code! I'll die from writing it!! In any event, systems programs should not be changed on simple whims like this. It's important that they be functional as they're expected to. -Kartik -- internet# rm `df | tail +2 | awk '{ printf "%s/quotas\n",$6}'` subbarao@phoenix.Princeton.EDU -| Internet kartik@silvertone.Princeton.EDU (NeXT mail) SUBBARAO@PUCC.BITNET - Bitnet
andre@targon.UUCP (andre) (04/24/91)
In article <1414@compel.UUCP> her@compel.UUCP (Helge Egelund Rasmussen) writes: >It is possible to give Oracle programs the username/password on the >command line, ie : > $ sqlplus scott/tiger >This is all very nice, BUT when another user execute 'ps -ef' he/she >can see the password! >Is it possible to hide the arguments, so that they won't show up in >the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)?? Sure you can, try this for size: main(argc, argv) int argc; char **argv; { char p[512]; if (argc == 2) { strcpy(p, argv[1]); memset(argv[1], '\0', strlen(argv[1])); sleep(30); /* time to check */ printf("argv[1] was %s \n",p); } return 0; } NOTE: untested code, but this explains the idea. -- The mail| AAA DDDD It's not the kill, but the thrill of the chase. demon...| AA AAvv vvDD DD Ketchup is a vegetable. hits!.@&| AAAAAAAvv vvDD DD {nixbur|nixtor}!adalen.via --more--| AAA AAAvvvDDDDDD Andre van Dalen, uunet!hp4nl!targon!andre
navarra@casbah.acns.nwu.edu (John 'tms' Navarra) (04/24/91)
In article <z91980@idunno.Princeton.EDU> subbarao@phoenix (Kartik Subbarao) writes: >In article <1991Apr23.090439.29024@casbah.acns.nwu.edu> navarra@casbah.acns.nwu.edu (John 'tms' Navarra) writes: >> >> I have been vaguely following this discussion and this might >> sound simple (and of course it might not work) but if you want to hide a >> process from ps (like a passwd call) how bout this: >> >> make a /bin/ps which does the following: >> >> exec /bin/psfiltered | grep -v passwd > >Changing a system program is a really Stupid way of solving the problem. >First, the person that wants to do this is not necessarily the superuser, >or one with kmem access. I realize that the intent was not necc for someone without superuser priveledges. That does not mean that there is not an interest in hiding passwd calls if you have superuser privs. > >Secondly, it's really simple to have the program read the "secret" >arguments from the tty (maybe even using getpass!), rather than have to have >them passed as arguments. Explain this one. If you don't have write access to other people's terminals (which most systems don't now a days) how will you get the 'secret' argument? > > >In any event, systems programs should not be changed on simple whims like >this. It's important that they be functional as they're expected to. > > -Kartik I agree with you that perhaps you should not muck around with the system programs. How bout a univeral alias that pipes grep -v passwd thru ps. The whole point of this is not to advertise that it is being done, but rather to stop people from trying to do 'timely' ps's. > > > >-- >internet# rm `df | tail +2 | awk '{ printf "%s/quotas\n",$6}'` > >subbarao@phoenix.Princeton.EDU -| Internet >kartik@silvertone.Princeton.EDU (NeXT mail) >SUBBARAO@PUCC.BITNET - Bitnet -- From the Lab of the MaD ScIenTiST: navarra@casbah.acns.nwu.edu
bennett@mp.cs.niu.edu (Scott Bennett) (04/24/91)
In article <1991Apr24.025417.5182@casbah.acns.nwu.edu> navarra@casbah.acns.nwu.edu (John 'tms' Navarra) writes: >In article <z91980@idunno.Princeton.EDU> subbarao@phoenix (Kartik Subbarao) writes: >> [text deleted --SJB] >> >>Secondly, it's really simple to have the program read the "secret" >>arguments from the tty (maybe even using getpass!), rather than have to have >>them passed as arguments. > > Explain this one. If you don't have write access to other people's > terminals (which most systems don't now a days) how will you get the 'secret' > argument? [X-ray laser on] Read what he said again. He mentioned nothing at all about other users' terminals. He said the *program* should read from the tty instead of looking at *argv[]. In other words, the morons who wrote the data base program in question should have been roundly chastised by their management. The product should never have been allowed out the door in a form like that. The data base program should be fixed. There is no need whatsoever to adulterate the operating system to fix a third- party software vendor's bungling. The program should *also* turn off the echo before reading the password. After all, it *is* a *password* that the program is requiring. [X-ray laser off] >> >> >>In any event, systems programs should not be changed on simple whims like >>this. It's important that they be functional as they're expected to. Precisely. >> >> -Kartik > > [text deleted --SJB] >>-- >>internet# rm `df | tail +2 | awk '{ printf "%s/quotas\n",$6}'` >> >>subbarao@phoenix.Princeton.EDU -| Internet >>kartik@silvertone.Princeton.EDU (NeXT mail) >>SUBBARAO@PUCC.BITNET - Bitnet > > >-- >From the Lab of the MaD ScIenTiST: > >navarra@casbah.acns.nwu.edu Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Spent a little time on the mountain, Spent a little time on the * * Hill, The things that went down you don't understand, But I * * think in time you will." Oakland, 19 Feb. 1991, first time * * since 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
subbarao@phoenix.Princeton.EDU (Kartik Subbarao) (04/24/91)
In article <1991Apr24.025417.5182@casbah.acns.nwu.edu> navarra@casbah.acns.nwu.edu (John 'tms' Navarra) writes: >>Changing a system program is a really Stupid way of solving the problem. >>First, the person that wants to do this is not necessarily the superuser, >>or one with kmem access. > >>Secondly, it's really simple to have the program read the "secret" >>arguments from the tty (maybe even using getpass!), rather than have to have >>them passed as arguments. > > Explain this one. If you don't have write access to other people's > terminals (which most systems don't now a days) how will you get the 'secret' > argument? What I mean is that, instead of accepting the password in an argument, the program should use getpass() or something to prompt the user to type it in after he runs the program. Clear? >>In any event, systems programs should not be changed on simple whims like >>this. It's important that they be functional as they're expected to. >> > I agree with you that perhaps you should not muck around with the system > programs. How bout a univeral alias that pipes grep -v passwd thru ps. > The whole point of this is not to advertise that it is being done, but rather > to stop people from trying to do 'timely' ps's. Gee, what if I have a program that's called "passwd", or some other argument that is called "passwd", or whatever you plan to grep -v. This is downright silly. An OS should not be made unpredictable in its behavior because one user can't write a program that calls getpass() to get sensitive information. It's really simple. Really it is. -Kartik -- internet# rm `df | tail +2 | awk '{ printf "%s/quotas\n",$6}'` subbarao@phoenix.Princeton.EDU -| Internet kartik@silvertone.Princeton.EDU (NeXT mail) SUBBARAO@PUCC.BITNET - Bitnet
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/26/91)
As quoted from <7326@auspex.auspex.com> by guy@auspex.auspex.com (Guy Harris): +--------------- | A quick look at the S5R3.0 "ps" indicates that if the "-l" flag is | given, the string in the u area is chopped off at 35 characters rather | than PSARGSZ characters, so a "w" flag might be useful there as well. +--------------- 3.0 is a bit old by now. The current behavior is that ps only shows the short command name (u_comm) unless the "-f" option is provided; then it prints out the entire u_psargs string. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 10m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/26/91)
As quoted from <1991Apr24.042539.20069@mp.cs.niu.edu> by bennett@mp.cs.niu.edu (Scott Bennett): +--------------- | of looking at *argv[]. In other words, the morons who wrote the data | base program in question should have been roundly chastised by their | management. The product should never have been allowed out the door | in a form like that. The data base program should be fixed. There is | no need whatsoever to adulterate the operating system to fix a third- | party software vendor's bungling. The program should *also* turn off | the echo before reading the password. After all, it *is* a *password* | that the program is requiring. +--------------- The program (Oracle) was designed for IBM mainframes and block-mode terminals. What else can you expect from such a losing origin? ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 10m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH