lath@geocub.greco-prog.fr (Laurent Lathieyre) (09/16/90)
MIDAY - SOS - HELP - ...---...---...---...---...---...--- I use an ATT 3b1 running Unix 3.51m. Yesterday I tried to change the default shell of the root user, so I modified the last field of the line concerning root in /etc/passwd (replacing /bin/sh by /bin/rootsh) /bin/rootsh is a shell script which make an echo to warn that you are super-user and make /bin/ksh /bin/rootsh has the following access rights -rwx------ root users :-( I can't anymore log in under root account... % su makes the following err mesage "No shell" % su root -c ls -l makes "Non-standard shell - denied" According to su(1) it seems possible to not use the shell indicated in /etc/passwd but the standard shell (/bin/sh) to execute a command... but I can't manage... What could I do ? To pray UnixGod that the redemption for silly administrators arrives ? :-( bouhhhh bouuuhh ouuhhhhoouuuuuu (i.e. french crybaby onomatopoeia) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- !\/! It's !\/! | Laurent Lathieyre | (oo) Better (o-) | E-mail : lath@geocub.greco-prog.fr | =\/= Manually =\/= -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
dave) (09/17/90)
In article <245@geocub.greco-prog.fr>, lath@geocub.greco-prog.fr (Laurent Lathieyre) writes: > > /bin/rootsh is a shell script which make an echo to warn > that you are super-user and make /bin/ksh > /bin/rootsh has the following access rights -rwx------ root users The shell script is your problem. If you aren't running 'sh' or 'ksh', whats going to run your shell script? What you need is a 'C' program! Try this one. Here --------- Snip Here --------- Snip Here --------- Snip Here --------- Snip /* rootsh.c * This program is a front end for ksh. It prints a warning and then execs * Korn shell. */ #include <stdio.h> main() { (void)printf("Warning: You are running a root shell.\n"); (void)execl("/bin/ksh", "ksh", 0); } Here --------- Snip Here --------- Snip Here --------- Snip Here --------- Snip To undo what you've done to /etc/passwd you probably have to boot from floppy unix and edit /etc/passwd. DAS -- David Snyder @ Snide Inc. - Folcroft, PA UUCP: ..!uunet!trac2000!das13!dave INTERNET: dave@das13.snide.com
floydd@chinet.chi.il.us (Floyd Davidson) (09/18/90)
In article <1070@das13.snide.com> dave@das13.snide.com (das13!dave) writes: >In article <245@geocub.greco-prog.fr>, lath@geocub.greco-prog.fr (Laurent Lathieyre) writes: >> >> /bin/rootsh is a shell script which make an echo to warn >> that you are super-user and make /bin/ksh >> /bin/rootsh has the following access rights -rwx------ root users > >The shell script is your problem. If you aren't running 'sh' or 'ksh', whats >going to run your shell script? What you need is a 'C' program! Try this one. The default in /etc/password can be set to a shell script, and in some cases it is very handy. You do not get the services of /etc/profile or a $HOME/.profile, instead you get exactly what you put in the shell script. Floyd
rlw@ttardis.UUCP (Ron Wilson) (09/19/90)
In article <1990Sep18.035609.9248@chinet.chi.il.us>, floydd@chinet.chi.il.us (Floyd Davidson) writes: >In article <1070@das13.snide.com> dave@das13.snide.com (das13!dave) writes: >>In article <245@geocub.greco-prog.fr>, lath@geocub.greco-prog.fr (Laurent Lathieyre) writes: >>> >>> /bin/rootsh is a shell script which make an echo to warn >>> that you are super-user and make /bin/ksh >>> /bin/rootsh has the following access rights -rwx------ root users >> >>The shell script is your problem. If you aren't running 'sh' or 'ksh', whats >>going to run your shell script? What you need is a 'C' program! Try this one. > >The default in /etc/password can be set to a shell script, and in some >cases it is very handy. You do not get the services of /etc/profile >or a $HOME/.profile, instead you get exactly what you put in the shell >script. It's been my experience that login and su insist on the shell for root be /bin/sh ---------------------------------------------------------------------------- About MS-DOS: "... an OS originally designed for a microprocessor that modern kitchen appliances would sneer at...." - Dave Trowbridge, _Computer Technology Review_, Aug 90 iwblsys\ rlw@ttardis uunet!rel.mi.org!cfctech!ttardis!rlw sharkey.cc.umich.edu/ rel.mi.org is currently sick - back in 2 weeks.
floydd@chinet.chi.il.us (Floyd Davidson) (09/20/90)
In article <2633@ttardis.UUCP> rlw@ttardis.UUCP (Ron Wilson) writes: >In article <1990Sep18.035609.9248@chinet.chi.il.us>, floydd@chinet.chi.il.us (Floyd Davidson) writes: >>In article <1070@das13.snide.com> dave@das13.snide.com (das13!dave) writes: >>>In article <245@geocub.greco-prog.fr>, lath@geocub.greco-prog.fr (Laurent Lathieyre) writes: >>>> >>>> /bin/rootsh is a shell script which make an echo to warn >>>> that you are super-user and make /bin/ksh >>>> /bin/rootsh has the following access rights -rwx------ root users >>> >>>The shell script is your problem. If you aren't running 'sh' or 'ksh', whats >>>going to run your shell script? What you need is a 'C' program! Try this one. >> >>The default in /etc/password can be set to a shell script, and in some >>cases it is very handy. You do not get the services of /etc/profile >>or a $HOME/.profile, instead you get exactly what you put in the shell >>script. > >It's been my experience that login and su insist on the shell for root be >/bin/sh True for the root login. Sorry if I implied that, it was not intended. Several things break if root doesn't default to /bin/sh by name. Others will break if it does not provide the functionality of sh. The previous statement implied that a C program would work as the default login shell and that a script would not. In fact either will work.
jan@bagend.uucp (Jan Isley) (09/20/90)
rlw@ttardis.UUCP (Ron Wilson) writes: >In article <1990Sep18.035609.9248@chinet.chi.il.us>, floydd@chinet.chi.il.us (Floyd Davidson) writes: >>In article <1070@das13.snide.com> dave@das13.snide.com (das13!dave) writes: >>>In article <245@geocub.greco-prog.fr>, lath@geocub.greco-prog.fr (Laurent Lathieyre) writes: >>>> >>>> /bin/rootsh is a shell script which make an echo to warn >>>> that you are super-user and make /bin/ksh >>>> /bin/rootsh has the following access rights -rwx------ root users Next time just set your prompt to warn you. PS1='root # ' or something similar... And if you make such dangerous experiments owned by bin, you can su bin, (if you gave bin a password) and fix it... next time. >>>The shell script is your problem. If you aren't running 'sh' or 'ksh', whats >>>going to run your shell script? What you need is a 'C' program! Try this If all you want is a warning that you are root, just changing your prompt keeps things simpler... I need things simple. :) >>The default in /etc/password can be set to a shell script, and in some >>cases it is very handy. You do not get the services of /etc/profile >>or a $HOME/.profile, instead you get exactly what you put in the shell >>script. Is this a *universal* *nix_ism? >It's been my experience that login and su insist on the shell for root be >/bin/sh bagend has run on the ksh *exclusively* since about an hour after it came to life many years ago. Not all ksh's are created equal, however. I do not recall any problem with root and ksh, ever. Several files in Cnews definately had some problems with the old ksh, but that was user news, not root. Of course none of this addresses the problem of how to get back root access which was the question. My mind is slipping, has this been openly discussed in this group? How to break into the system? Very recently there was a discussion about this in something.admin and of course half the comments were "why not tell people how to break in" and the other half were "if you tell I'll burn your computer down". I don't think it is in the FAQ file...? Lenny? Should it be? Well, I am sitting on the fence. How about a hint? Boot your Floppy boot disk, (foundation set disk #1?). Insert the floppy file system disk (foundation set disk #2) when it asks for it. When you get a message on the screen warning you of impending doom to your file system, asking if you want to continue, *** DO NOT TYPE Y *** If you answer Y|yes, the contents of your hard disk will go away. Of course, this would solve the problem, ass_u_me ing you have backups. At this point, if you are not prepared to accept the posibility that *you* might *really* trash your system because you listened to me, (not your first mistake!) type N and call someone who knows and offer them money|beer|land|whatever to come over and help... If you are willing to accept all the blame if you screw it up, when the systems prompts you for permission to continue type: Del that is the Shift-Esc key. You will be presented with a familiar prompt. If the rest of this exercise is not obvious, email might be a more appropriate place to discuss it. jan -- Signatures!? | Jan Isley jan@bagend We don't need no stinking signatures. | known_universe!gatech!bagend!jan
dt@yenta.alb.nm.us (David B. Thomas) (09/20/90)
rlw@ttardis.UUCP (Ron Wilson) writes: >It's been my experience that login and su insist on the shell for root be >/bin/sh I changed my /etc/passwd so root runs /bin/ksh with no surprising side effects. Login and su both work as advertised. Of course, I still wish su didn't insist on mucking with the path. David
gentry@kcdev.UUCP (Art Gentry) (09/21/90)
In article <2633@ttardis.UUCP> rlw@ttardis.UUCP (Ron Wilson) writes: }In article <1990Sep18.035609.9248@chinet.chi.il.us>, floydd@chinet.chi.il.us (Floyd Davidson) writes: }>In article <1070@das13.snide.com> dave@das13.snide.com (das13!dave) writes: }>>In article <245@geocub.greco-prog.fr>, lath@geocub.greco-prog.fr (Laurent Lathieyre) writes: }>>> }>>> /bin/rootsh is a shell script which make an echo to warn }>>> that you are super-user and make /bin/ksh }>>> /bin/rootsh has the following access rights -rwx------ root users }>> }>>The shell script is your problem. If you aren't running 'sh' or 'ksh', whats }>>going to run your shell script? What you need is a 'C' program! Try this one. }> }>The default in /etc/password can be set to a shell script, and in some }>cases it is very handy. You do not get the services of /etc/profile }>or a $HOME/.profile, instead you get exactly what you put in the shell }>script. } }It's been my experience that login and su insist on the shell for root be }/bin/sh not true! I run 23 3b2's of various vintages and unix releases, all of them have root's default shell defined as ksh. ie. root:askjdfhja:0:1:Sysadmin(Art):/:/bin/ksh I have no problems with this what-so-ever. I have not tried pointing root's shell to a script file instead of a shell, though I do this regularly with users id's with no problems either. For those users that I don't what to have access to a shell at all, I'll point their "shell" to a script, one entry of which is SHELL="", which prevents them from getting to a shell at all. | R. Arthur Gentry Gentry and Associates Excelsior Springs, MO 64024 | | Email: gentry@genco.uucp ATTMail: attmail!kc4rtm!gentry | | The UNIX BBS: 816-221-0475 The Bedroom BBS: 816-637-4183 | | $include {std_disclaimer.h} "I will make a guess" - Spock - STIV |
bdb@becker.UUCP (Bruce D. Becker) (09/21/90)
In article <2633@ttardis.UUCP> rlw@ttardis.UUCP (Ron Wilson) writes: |In article <1990Sep18.035609.9248@chinet.chi.il.us>, floydd@chinet.chi.il.us (Floyd Davidson) writes: |>In article <1070@das13.snide.com> dave@das13.snide.com (das13!dave) writes: |>>In article <245@geocub.greco-prog.fr>, lath@geocub.greco-prog.fr (Laurent Lathieyre) writes: |>>> |>>> /bin/rootsh is a shell script which make an echo to warn |>>> that you are super-user and make /bin/ksh |>>> /bin/rootsh has the following access rights -rwx------ root users |>> |>>The shell script is your problem. If you aren't running 'sh' or 'ksh', whats |>>going to run your shell script? What you need is a 'C' program! Try this one. |> |>The default in /etc/password can be set to a shell script, and in some |>cases it is very handy. You do not get the services of /etc/profile |>or a $HOME/.profile, instead you get exactly what you put in the shell |>script. | |It's been my experience that login and su insist on the shell for root be |/bin/sh You can login to a shell script from /etc/passwd - however "su -" won't work. "su" doesn't care as long as it's a program, but "su -c" will complain if it isn't "/bin/sh". Interestingly enough, this doesn't appear to be the case from within a crontab. I've been running the "root" passwd entry with /bin/ksh for some months without hassles so far. When I "su root -c ..." from any interactive shell, su complains: "Non-standard shell - denied". ...But the same line inside crontab works fine... Cheers, -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!uunet!mnetor!becker!bdb _< /_ "I still have my phil-os-o-phy" - Meredith Monk
res@cbnews.att.com (Robert E. Stampfli) (09/23/90)
> > /bin/rootsh is a shell script which make an echo to warn > > that you are super-user and make /bin/ksh > > /bin/rootsh has the following access rights -rwx------ root users > > The shell script is your problem. If you aren't running 'sh' or 'ksh', whats > going to run your shell script? What you need is a 'C' program! Try this > one. ... There is still a subtle problem. You may get this to appear to work, but it is still a "non-standard shell" to su. When cron goes to run a job as root -- I bet you have plenty of "su root -c" or "su root %" lines in /usr/lib/crontab -- it will fail with "Non-standard shell - denied". The same holds true for anyone thinking of making /bin/ksh your standard root shell. Root is one account best left alone. -- Rob Stampfli / att.com!stampfli (uucp@work) / kd8wk@w8cqk (packet radio) 614-864-9377 / osu-cis.cis.ohio-state.edu!kd8wk!res (uucp@home)
yarvin-norman@cs.yale.edu (Norman Yarvin) (09/23/90)
res@cbnews.att.com (Robert E. Stampfli) writes: >The same holds true for anyone thinking of making /bin/ksh your standard root >shell. Root is one account best left alone. Since noone's mentioned it... a common solution is a separate-but-equal "kroot" account, which uses /bin/ksh. Of course, you still can't use ksh for su -c, but there are precious few times that's necessary. -- Norman Yarvin yarvin-norman@cs.yale.edu