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