Re: "No Shell"

From: Jose R. Valverde (jr_at_cnb.uam.es)
Date: 03/12/04

  • Next message: Jose R. Valverde: "Re: INODES! I'm so confused! Please help!" 
    Date: Fri, 12 Mar 2004 16:39:36 +0000 (UTC)

    > One of these days you will discover 'sudo', this will cure your tendency
    > to replace root's shell. There is simply no need to login as root - ever, login
    > as a "un-priviligied user" and sudo to whatever you need. As extra bonus
    > you don't have to guard(and spread) root's password anymore.
    >

    'Nuff nonsense.

        In most UNIX systems the shell root uses has no relevance whatsoever.
    Nor should it. If it does, it's the system fault, and no one else.

        Root is just another user. The general phylosphy is that root can do
    as s/he likes/needs. And change the shell or whatever it s/he just well damn
    pleases (or needs to) is a part of it. That changes should be taken cautiously
    is true, but they can and should be made.

        There may be problems though, some of which are related to bad programming
    and others to system maintenance. Any good sysadmin should know about them and
    the correct workarounds. Saying sudo is the final solution is as well nonsense.
    Much more imagining it will protect any password.

        There are many reasons to taylor a system. What's important is that changes,
    and their rational, are documented for successors to be able to take their own
    decisions. There are not stone-cast laws in system administration, only
    exceptions, workarounds and advice. It helps to go by the book when you
    start, but the mark of a good professional is knowing when to bend the
    rules to his/her advantage.

        For more details:
        
        - bad programming problems: if there are scripts that require sh but
    do not use the #!/bin/sh magic, then changing root's shell to something
    not sh-compatible will break them. Not that it matters much, after some
    time one learns to use 'sh script' and it's fixed, or starts sh before
    running them. Other than that nothing else should depend on root shell,
    and if it does, it is badly designed

        - it may be that the selected shell is not 'allowed', but then
    changing the definition of allowed shells (e.g. /etc/shells) should do.
    Or renaming the shell to sh

        - sysadmin woes: if a program (the shell) is split among various
    file systems and any of them breaks, you'll be in trouble. Solution:
    trivial, place all pieces in the same file system or compile the
    program statically. There's been argument whether anything root uses should
    be dynamically linked at all, but that's probably moot today. Other than
    that, which shell/program/script/tool you use should not matter.

        - sudo and passwords: crap. Sudo is nice for what it was intended:
    allowing users to run specific privileged commands. It won't protect any
    password. Old timers may remember an attack in the early '90s on Suns that
    would put them in promiscuous mode and grab the first N (200) chars of any
    connection in the LAN. The typical sysman would login unprivileged and then
    'su' to root, typing his/her password which would be in the grabbed buffer.
    Any kay-punch-grabbing attack would do the same to sudo or any other.

        - protecting passwords is and will always be a need and a must. Sorry
    to bear bad news
        
        - sysadmin WOES: pity the sysadmin who inherits a plain vanilla,
    untouched system because his/her antecessor feared or dared not change
    anything. Truth is, few of us look all the same or do the same thing, most
    systems need tweaking and that's what we are paid for. An untouched system
    has not been tailored, updated, upgraded, fixed... In short, it's a wreck.

        So what? If a vulnerability in sh is reported, should it not be
    changed to -say- a new version? If it may, what precludes anyone installing
    an extended shell? Or another one instead? And if it is compatible, how will
    the system tell? Why should it?

        If the system requires specialized customization, are you to avoid it
    because 'root' should not be touched? What is root there for then? If it were
    an embedded system and instead of sh, another shell was needed, are you
    going to tell to your boss 'uh, oh, that's a no-no'? To yourself? C'mon!

        I've been using 'tcsh' as root shell for well over ten years now on
    *BSD, Ultrix, OSF/1, Tru64, Irix, AIX, Linux, Sun/OS and Solaris (at least)
    and always could manage the systems without any problem. I stomped on some
    of the mentioned mistakes, but there always was a workaround and never
    a real need for sh/ksh/csh/whatever. I still write most administration
    scripts in 'sh' if you wonder about it, and switch over to sh or bash
    for some specific tasks. For me that's being a pro: knowing my way around
    well enough to make the systems work for me without a glitch.

        Your successors only need that all changes be documented and their
    rational explained. Even if it is a matter of personal preference. Much
    more then, so they may change in the future to their needs. If they are
    unable to read the documentation you leave behind, then they are not
    suited to the position or you didn't write it correctly.

        There are many reasons to change things in a system, that's what a
    sysadmin is for. Spreading FUD is not professional. Explaining how to
    work around problems and find solutions is.

                                                        j 

    -- 
	These opinions are mine and only mine. Hey man, I saw them first!
			    José R. Valverde
	De nada sirve la Inteligencia Artificial cuando falta la Natural
  • Next message: Jose R. Valverde: "Re: INODES! I'm so confused! Please help!"

    Relevant Pages