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) --------------------------------------------------------------------------------
rjd@occrsh.ATT.COM (01/06/88)
>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 Some problems can occur if the stock Bourne shell is changed. I linked /bin/ksh to /bin/sh on a 3B2 model 310 running the stock AT&T System V factory load 2.0.5 (makes sense, as I am here at the factory). Actually I just copied over /bin/sh (and saved a copy of sh over in /usr). Well, suddenly all sorts of things quit working (a suspicion I had, which was the reason I saved a copy of sh). The most memorable was that at(1) bombed. When at(1) sets up the job file in /usr/spool/cron/atjobs, it saves the COMPLETE current enviroment of the user. Well, it just so happens that some variables were marked "readonly", most notably PPID. When the atjob was executed, it nonetheless tried to set PPID (or was it PWD?), notwithstanding its readonly status. At the step where it was trying to set the readonly variable, it bombed. .....So I moved the original Bourne shell back to /bin/sh.... Randy
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