Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!sequoia!rpp386!jfh From: jfh@rpp386.cactus.org (John F Haugh II) Newsgroups: comp.unix.wizards Subject: Re: file attributes Message-ID: <19407@rpp386.cactus.org> Date: 26 Jun 91 13:27:02 GMT References: <1991Jun20.021749.12011@gpu.utcs.utoronto.ca> <1991Jun21.191521.12644@sco.COM> <8509@auspex.auspex.com> <1991Jun25.192743.8968@sco.COM> Reply-To: jfh@rpp386.cactus.org (John F Haugh II) Organization: Cheeseburger in Paradise, Le Select, St Barts., FWI Lines: 31 In article <1991Jun25.192743.8968@sco.COM> john@sco.COM (John R. MacMillan) writes: >|However, depending on what meaning (if any) you'd assign to "bloat", >|"the #! hack" may or may not "bloat" the kernel; by my count, it adds 60 >|lines to "kern_exec.c" in 4.3BSD, for example. > >Like you, I'm not a fan of the term ``bloat''. My reason for >mentioning #! was that I felt it belonged in user code, not because >it's big, but because there's no particularly good reason to put it in >the kernel. I'm no fan of bloat either, and I rail against it at every oppurtunity. The "#!" "hack" is not "bloat". As Guy (that was Guy Harris, right?) pointed out, the change is really very minimal. It gets made in exactly one place (the kernel) instead of many others (every command that might include a library module which executes another command) and brings with it certain (dubious) advantages (like set-UID scripts ...) >I don't consider it a loss. If you really REALLY need setuid scripts, >that too can be done without kernel support (ksh has an suid_exec >program to do this). This has the added advantage that it gives the >sysadmin control over setuid scripts. This points directly to why it should be handled in the kernel. We know exactly how to execute shell scripts, it isn't that hard, and we can do it right in the kernel with 60 lousey little lines of code. [ Plus a few to close the set-UID holes if you really insist on set-UID scripts ] -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "UNIX signals are not interrupts. Worse, SIGCHLD/SIGCLD is not even a UNIX signal, it's an abomination." -- Doug Gwyn