lenny@icus.UUCP (Lenny Tropiano) (01/03/88)
What is the problem giving root (or any login for that matter) /bin/ksh
for the default login shell and then using the "su <name> -c <cmd>" to
execute a command? I keep getting:
$ su root -c "rm xx"
Password:
Non-standard shell - denied
Does the "-c" option only work with the Bourne shell (/bin/sh)? I would
like root to have /bin/ksh. I have to cludge it up with leaving the
default shell blank in /etc/passwd and then in the .profile put a:
exec /bin/ksh
This is annoying.
-Lenny
--
============================ US MAIL: Lenny Tropiano, ICUS Computer Group
IIIII CCC U U SSSS PO Box 1
I C C U U S Islip Terrace, New York 11752
I C U U SSS PHONE: (516) 968-8576 [H] (516) 582-5525 [W]
I C C U U S AT&T MAIL: ...attmail!icus!lenny TELEX: 154232428
IIIII CCC UUU SSSS UUCP:
============================ ...{uunet!godfre, harvard!talcott}!\
...{ihnp4, boulder, mtune, bc-cis, ptsfa, sbcs}! >icus!lenny
"Usenet the final frontier" ...{cmcl2!phri, hoptoad}!dasys1!/wjc@ho5cad.ATT.COM (01/04/88)
In article <200@icus.UUCP> lenny@icus.UUCP (Lenny Tropiano) writes: > [su with "-c" problem described] > Does the "-c" option only work with the Bourne shell (/bin/sh)? I would > like root to have /bin/ksh. I have to cludge it up with leaving the > default shell blank in /etc/passwd and then in the .profile put a: > > exec /bin/ksh > > This is annoying. I don't know why it's done that way, but it looks like the check for /bin/sh is coded into /bin/su. (From a look at the binary.) Another ploy for getting ksh for root is to simply link /bin/ksh on top of /bin/sh. I've been running this way for quite a while with no problems (3.5). I do recall some ancient problems with cron scripts breaking and log files growing forever in the 2.5/3.0 days, but something fixed that. Bill Carpenter (AT&T gateways)!ho5cad!wjc HO 1L-410, (201)949-8392
still@usceast.UUCP (Bert Still) (01/06/88)
In article <200@icus.UUCP> lenny@icus.UUCP (Lenny Tropiano) writes: >What is the problem giving root (or any login for that matter) /bin/ksh >for the default login shell and then using the "su <name> -c <cmd>" to >execute a command? I keep getting: > >$ su root -c "rm xx" >Password: >Non-standard shell - denied > > -Lenny Strange... I use csh (the Berkeley shell) for root on my 3B2/300, and I just tried the above (from inside csh under my ``ordinary'' users account) -- it works for me. I don't have access to ksh, so I can't try anything with it. I would be interested in which release of System V you're using. My version is release 2.0. bert -------------------------------------------------------------------------------- shar is actually an ancient term meaning "some assembly required" -------------------------------------------------------------------------------- CSNET: still@cs.scarolina.edu # US SNAIL: Bert Still # Dept of Mathematics BITNET: T410119@UNIVSCVM # University of South Carolina # Columbia, SC 29208 -------------------------------------------------------------------------------- UUCP: ...seismo!ncr-sd!ncrcae!usceast!still (BSD4.3) ...usceast!porthos!still (Ultrix1.1) ...usceast!porthos!hermes!still (SVr2) -------------------------------------------------------------------------------- Newsgroups: unix-pc.general,comp.sys.att,comp.unix.questions,comp.unix.wizards Subject: Re: Non-standard shell and su. Summary: Expires: References: <200@icus.UUCP> Sender: still@cs.scarolina.edu (Bert Still) Reply-To: still@usceast.UUCP (Bert Still) Followup-To: Distribution: Organization: University of South Carolina, Columbia Keywords: su, root, security, /bin/ksh In article <200@icus.UUCP> lenny@icus.UUCP (Lenny Tropiano) writes: >What is the problem giving root (or any login for that matter) /bin/ksh >for the default login shell and then using the "su <name> -c <cmd>" to >execute a command? I keep getting: > >$ su root -c "rm xx" >Password: >Non-standard shell - denied > > -Lenny Strange... I use csh (the Berkeley shell) for root on my 3B2/300, and I just tried the above (from inside csh under my ``ordinary'' users account) -- it works for me. I don't have access to ksh, so I can't try anything with it. I would be interested in which release of System V you're using. My version is release 2.0. bert -------------------------------------------------------------------------------- shar is actually an ancient term meaning "some assembly required" -------------------------------------------------------------------------------- CSNET: still@cs.scarolina.edu # US SNAIL: Bert Still # Dept of Mathematics BITNET: T410119@UNIVSCVM # University of South Carolina # Columbia, SC 29208 -------------------------------------------------------------------------------- UUCP: ...seismo!ncr-sd!ncrcae!usceast!still (BSD4.3) ...usceast!porthos!still (Ultrix1.1) ...usceast!porthos!hermes!still (SVr2) --------------------------------------------------------------------------------
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (01/06/88)
In article <264@ho7cad.ATT.COM> wjc@ho5cad.ATT.COM writes: | In article <200@icus.UUCP> lenny@icus.UUCP (Lenny Tropiano) writes: | > [su with "-c" problem described] | Another ploy for getting ksh for root is to simply link /bin/ksh on | top of /bin/sh. I've been running this way for quite a while with no | problems (3.5). I do recall some ancient problems with cron scripts | breaking and log files growing forever in the 2.5/3.0 days, but | something fixed that. Any script which uses the caret (^) for pipes will break. I just posted a note in another group about this, maybe I should put it on the bugs group as well. A good example of this is "style" and "diction" from WWB. I use these a lot, so I found the problem very early on. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
stpeters@dawn.steinmetz (Dick St.Peters) (01/07/88)
In article <264@ho7cad.ATT.COM> wjc@ho5cad.ATT.COM writes: >Another ploy for getting ksh for root is to simply link /bin/ksh on >top of /bin/sh. I've been running this way for quite a while with no >problems (3.5). This can be very dangerous if any of your scripts expect to use symlinks to reach remote parts of a filesystem: cd <symlink> cd .. and you're back where you began, which is not how other shells behave and is probably not what your script expected. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/07/88)
In article <8389@steinmetz.steinmetz.UUCP> dawn!stpeters@steinmetz.UUCP (Dick St.Peters) writes: >This can be very dangerous if any of your scripts expect to use >symlinks to reach remote parts of a filesystem: > cd <symlink> > cd .. >and you're back where you began, which is not how other shells behave >and is probably not what your script expected. Lots of other shells behave this way; ours for example. I doubt that many scripts really would plan on the 4.3BSD /bin/sh behavior occurring in such a case. Far more likely, they're expecting the behavior of ksh or the BRL Bourne shell.
stpeters@dawn.steinmetz (Dick St.Peters) (01/08/88)
In article <6974@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>[quote of my warning about how ksh's cd behaves with symlinks] >Lots of other shells behave this way; ours for example. > >I doubt that many scripts really would plan on the 4.3BSD /bin/sh >behavior occurring in such a case. Far more likely, they're >expecting the behavior of ksh or the BRL Bourne shell. I beg to differ, but we'd have to count them all to prove who's right. Problems likely to be more common than the one I originally cited are that under ksh cd <symlink> ls ../foo always gives "../foo not found". Also, if [ -f ../foo ] always yields false. Both these results are as described even if both a real ../foo exist and a <back up the symlink>/foo exist. These are not unlikely things to find in scripts, and this behavior badly limits the usefulness of symlinks, which are extremely useful if your shell behaves. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
ekrell@hector.UUCP (Eduardo Krell) (01/08/88)
In article <8400@steinmetz.steinmetz.UUCP> dawn!stpeters@steinmetz.UUCP (Dick St.Peters) writes: >Problems likely to be more common than the one I originally cited are >that under ksh > cd <symlink> > ls ../foo >always gives "../foo not found". Also, > if [ -f ../foo ] >always yields false. On the other hand, of course, a problem likely to be even more common that these are that under csh or any other shell that treats symlinks the way BSD does cd /usr/include/sys cd .. doesn't put you in /usr/include (which is what I want all the time). Also, ls ../*.h doesn't list the header files in /usr/include (which is what I would expect). All this assumes /usr/include/sys is a symbolic link (which it is in most BSD machines). Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,ucbvax}!ulysses!ekrell
stpeters@dawn.steinmetz (Dick St.Peters) (01/11/88)
In article <3333@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: >>[my comments on ksh behavior in the presence of symlinks] >[comments on csh behavior i.t.p.o.s.] Before we go off on a your-shell/my-shell tangent, remember that this started when I warned that copying ksh on top of /bin/sh (which somebody had suggested) could be dangerous. The point is *not* which behavior is better (the user should have his/her choice). If not specifyable, the behavior should at least be predictable. Having just acquired the task of writing complex installation scripts for a system whose sheer size necessitates symlinks, I find it a bit unnerving that /bin/sh behaves differently on different systems. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
tim@doug.UUCP (Tim J Ihde) (01/12/88)
I can't find the original article here, so forgive me if I'm completely off in the ether someplace; but on this general topic I can give one warning from experience. We were having some questionable security problems, and just wanted to be able to log what people were doing after they had su'd. The quickest thing one fellow here could think of was to change the /etc/passwd entry for root so that it used ksh as the default shell instead of sh. This worked quite well; the .history file told us everything we wanted to know (funny how people who know about 'vi /usr/adm/sulog' don't try 'vi /.history'). What we hadn't been thinking about was that our ksh was located in /usr/local/bin/ksh. Which is not located on the root filesystem. So it isn't avaliable on bootup to run all those nice shell scripts in /etc. Of course, this little problem was not noticed until we needed to bring the system up after shutting down for some PM. Well, at least we had backups! -- Tim J. Ihde ihnp4!ctsmain!doug!tim (201) 535-9897 Ok, we can all agree that this is my fault.