mouse@mcgill-vision.UUCP (der Mouse) (11/12/86)
> Subject: 4.3 /bin/passwd does not deal with /etc/shells properly > Repeat-By: > Run passwd to request a new shell. Ask for a shell that is > before your old shell in the list in /etc/shells. > Subject: 4.3 vipw does not allow root to have a shell in /etc/shells > Repeat-By: > Edit the password file with vipw, and try to change root's > shell to a shell listed in /etc/shells, but not /bin/sh or > /bin/csh, (e.g., /bin/ksh). Watch vipw complain about mangling > the password file. Could someone explain what this /etc/shells silliness is all about? Why joe user can't change his shell to whatever he pleases?? I see no reason to restrict users in their choice of shells - in fact, this is one of the things usually quoted as a great strength of UNIX. Or is this an attempt to protect people from themselves? Why assume they *need* protection from themselves? If I wanted to run another shell on a system with this sort of stupidity I'd just specify /bin/sh and have a one-line .profile exec /.../myshell "$@" or use /bin/csh and have a similar .cshrc -- so you really don't buy anything. Just user aggravation and extra trash to maintain. By the way, I would argue that the second "bug" I quoted above is not a bug. One of the uses of root is to fix things when they break. Suppose ksh is broken? Then you can't log in as root, you have to boot single-user (involving bringing the system down). der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu [USA NSA food: terrorist, cryptography, DES, drugs, CIA, secret, decode]
rml@hpfcdc.HP.COM (Bob Lenk) (11/13/86)
> Could someone explain what this /etc/shells silliness is all about? > Why joe user can't change his shell to whatever he pleases?? I see no > reason to restrict users in their choice of shells I won't claim to explain what it's all about. One reason that a system administrator might want to restrict the login shells available is to insure that every user who logs on executes some specific code (in /etc/profile or analogous file for other permitted login shells). In that case a one-line .profile which exec's another shell is a good solution for everyone involved. Another reason that some checking must be done is so a user can't install a shell like "/bin/sh\nbreakin::0:1::/:/bin/sh" (that doesn't require /etc/shells, but requires some check). > in fact, this is > one of the things usually quoted as a great strength of UNIX. That strength still exists, but the system administrator is permitted to limit the freedom. Perhaps some systax in /etc/shells (like an entry of * ) which permits any shell to be installed (subject to security checks) would be nicer. Bob Lenk {hplabs, ihnp4}!hpfcla!rml
ron@brl-sem.ARPA (Ron Natalie <ron>) (11/14/86)
One reason is that /etc/shells is used for other stuff as well. For example FTP will not allow FTP logins for accounts with non-standard shells. Some sites have accounts like "finger" or "who" which run with a shell, uucp logins almost always invoke "uucico", you don't want people to come in by some other non-login means to these accounts and be able to bust out of the rather limited shell that they were given. -Ron