Date: Tue, 4 Mar 1997 13:44:26 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: somsky@dirac.phys.washington.edu (William R. Somsky) Cc: hackers@freefall.freebsd.org Subject: Re: java support under FreeBSD. Message-ID: <199703042044.NAA10311@phaeton.artisoft.com> In-Reply-To: <199703041926.LAA24593@dirac.phys.washington.edu> from "William R. Somsky" at Mar 4, 97 11:26:04 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > - I can't see any decent way to automagically execute <name>.class when > > > a user types <name>. If typing <name>.class is considered ok, why > > > is typing 'java <name>' not? If the solution is to add a soft link, > > > why not write a two-line script at once and avoid the need for kernel > > > support altogether? > > > > There is no way to do this, short of hacking the shell, or doing the > > expression expansion for path expressions in the kernel, rather than > > in the shell (there are a lot of good reasons you'd want to do this, > > actually, but it's complicated unless you do it precisely the right > > way when you do it). > > Hmm... Although it would be useful, I'd argue that any path/extention/etc > expansion does _not_ belong in the kernel's implementation of 'exec'. > The kernel is told to 'exec' a specified _file_ by name. Now, it would > IMHO, be valid for it to do whatever is necessary to execute _that_ > file, but it shouldn't go groveling around to find some other file, > otherwise you get into the problem (annoyance, possible trojan horse attack) > where "/bin/foo" _used_ to be a valid command, but got deleted, or > chmod -x'd, and then an exec of "/bin/foo" finds a completely different > "/bin/foo.class" instead, with no warning whatsoever. Not good. SUID > wrappers where you explicitly exec a file by full pathname, then get this > unforseen vulnerability. I think you are confusing PATH interpretation with terminal component evaluation. If you supply an explicit path, then your "su vunerability" is not there (and that's how you should do it). The reason for the terminal component interpretation, including the globbing, in the kernel is that you want to interpret "name" as if the user had typed "name.class" by virtue of the JAVA execution class loader grovelling for "name". The "other good reasons" include not pushing back non-matching directory entries across the getdents interface. This could speed up the SAMBA code significantly, not to mention the commercial Novell server code (which must make two passes to list first directories, then files). Saves a lot of grovelling around in user space, and a lot of kernel boundry crossings. If you were serious, the directory lookup would return full stat information. So would open, read, write, close, etc. (most of the time it could be cached in user space, but if it changed, the cached value should be updated). Consider an "ls -lR" or a "find". Also consider that a DOS OPen must return STAT information, so any DOS client would benefit. Finally, understand that a lookup is done for a reason, generally to actually do something with the resulting inode, and locality of reference suggests that it would be a win to force the thing into core (even if you aren't pessimal old DOS, always doing a "search" followed by a seperate "open", when all you wanted to do was reall an open). > Now, rather than making any 'file extension search' capability part of > exec(2), where, as I argued above, it shouldn't go, the more reasonable > place to put it (if you want it) is in execlp(3) and execvp(3) which > are already doing searches through the PATH. Searches through extensions > would logically go in the same place. > > However, I'd also argue against having _any_ "entention search" capability > in either the system library _or_ any standard shell as being to "DOS-y" > and not in the Unix spirit. If we have the command "foo" find and run > the java "foo,class", do we also want "bar" to find and run the script > "bar.sh" or (yuuch) "bar.bat"? And I've still seen people who insiste > on compiling their program "bletch.c" into "bletch.exe" -- should "bletch" > then find and run "bletch.exe"? And what about search order? What if > you ask to run "blotch" and there exists /bin/blotch.class, /usr/bin/blotch, > /usr/local/bin/blotch.sh, and ~/bin/blotch.exe? See above. "DOS'sy" it may be, but it is also a general efficiency boost (the "ls -lR" and "find" cases alone save 50% on the number of system calls necessary. So do tar, cpio, zip, etc.: anything that needs a stat or fstat following a lookup. Like a GUI file browser, for example.). Unfortuantely, the current VFS framework is not stable enough to allow this level of FS research... and the Lite2 patches make a number of things worse, not better. 8-(. > > I have no problem with "name.class"... if someone does, then they > > need to rename their "exectuable" to "name" instead of "name.class". > > I agree with this. Yes... but like I said, I'm not close enough to the problem to know if JAVA places significance on the ".class" extension. If it does, this won't work. > > Yes. This is what I would suggest. The sysctl CLASSPATH is the > > "default path". > > > > I would maybe go so far as to say that if the user specifies a CLASSPATH, > > it should override, entirely, the sysctl CLASSPATH for invocations by > > that user. > > Hmm... could we do something like one of the TeX implementations (Karl > Berry's, and it might carry ofer into Thomas Esser's) does? A fully > specified CLASSPATH (or perhaps EXECCLASSPATH if you want to keep it > separate from other uses of CLASSPATH by netscape and other non-kernel > uses) overrides the sysctl CLASSPATH, but if there is a leading/trailing/ > doubled-internal ":", the sysctl CLASSPATH is inserted into that point. > So if I just want to add my ~/bin/java to thefront of the EXECCLASSPATH, > I just "setenv EXECCLASSPATH ~/bin/java:" I like this better than my suggestion. 8-). > Hmm... But do we really want a kernel(2) item to be reading stuff from > the environment? Does any other "section-two" call use environmental > information? If not, I'd argue against using any env info here. The execve(2) does already. And the program loader (shell) examines the path. There is also the crt0.o for ld.so (ld.so should areguably be mapped into the process address space by the execution class code in the kernel, instead of by the crt0.o... that's one of the reasons a non-"branded" ELF binary is such a bad thing). We could argue that the execve(2) call should be changed to not forward the envp from the caller's address space. Indeed, the environment should be in the kernel as a user manipulable data (via system call) off the proc struct. POSIX is broken in this area, to some degree, in that it implies the envp for some section(3) wrappers. I provided a getenv/setenv implementation in late 1994 that actually did this: effectively, it was an implementation of logical name tables. The initial reason for doing this was to support kernel expansion of environment variables in the interpretaion of variant symbolic links (the name space intrusion was done via "$(varname)" constructs -- unlikely to interfer with any existing, useful symbolic links). There are a couple of nice side effects of this, not the least of which is that it allows inheritance of "system logical names" (initd's LNT) and "group logical names" (the process group leader's LNT) and solves the age-old problem of "how can a child modify the parent's environment?". Logical names implemented this way, obviously, would enable you to solve all of the CLASSPATH problems neatly, cleanly, and with little or no real coding effort: set up the system logical "CLASSPATH" and override it, as necessary, in the user's login or process environment. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703042044.NAA10311>