Discussion:
toor shell: /rescue/sh?
Thomas Klausner
2013-12-04 21:22:03 UTC
Permalink
Hi!

Since toor is the fallback account for trouble, would it make sense to
use /rescue/sh as its shell (instead of /bin/sh), to make it even more
trouble-proof?
Thomas
Patrick Welche
2013-12-04 21:24:08 UTC
Permalink
Post by Thomas Klausner
Hi!
Since toor is the fallback account for trouble, would it make sense to
use /rescue/sh as its shell (instead of /bin/sh), to make it even more
trouble-proof?
Yes... Didn't it use to be root = /bin/csh, toor = /bin/sh, so when they
both started using the same shell, toor lost its purpose...

Patrick
Brett Lymn
2013-12-05 09:16:25 UTC
Permalink
Post by Patrick Welche
Yes... Didn't it use to be root = /bin/csh, toor = /bin/sh, so when they
both started using the same shell, toor lost its purpose...
I repurposed toor to be /usr/pkg/bin/bash - root for emergency fix ups,
toor for lazy sysadmin :)
--
Brett Lymn
Staple Guns: because duct tape doesn't make that KerCHUNK sound - xkcd.com
Erik Fair
2013-12-05 19:19:27 UTC
Permalink
A fine idea given that we've gone and done the shared library thing everywhere except /rescue and shared libraries are prone to getting stomped or blasted with very unhappy results.

Of course, that means that those shells should be listed in /etc/shells.

Erik <***@netbsd.org>
Mouse
2013-12-05 19:43:59 UTC
Permalink
Post by Erik Fair
Of course, that means that those shells should be listed in
/etc/shells.
Actually, /etc/shells should be scrapped.

As far as I can tell, it was invented to close the "chsh with newlines
in the shell name" hole, then got co-opted as a "this is/isn't a
general-purpose user" flag. It isn't a good solution to either of
those problems; the API to it, which is what programs (as oppsoed to
admins) see, is broken even worse, both in fundamental design (overload
the shell as a "is/isn't a general-purpose account" flag) and detailed
design (the interface should have been "is this shell OK?", not "give
me a list of the OK shells", since the latter works only when the list
is small and easily enumerable, thus making it infeasible to, for
example, allow an admin to configure "any shell owned by root is OK",
_even by replacing the implementation_). It's also broken
philosophically, in that it breaks the "the shell is just another
program" paradigm Unix had previously always had.

Perpetuating the mistake will not make it any less of a mistake.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Marc Balmer
2013-12-05 19:59:42 UTC
Permalink
Post by Mouse
Post by Erik Fair
Of course, that means that those shells should be listed in
/etc/shells.
Actually, /etc/shells should be scrapped.
agreed.
Post by Mouse
As far as I can tell, it was invented to close the "chsh with newlines
in the shell name" hole, then got co-opted as a "this is/isn't a
general-purpose user" flag. It isn't a good solution to either of
those problems; the API to it, which is what programs (as oppsoed to
admins) see, is broken even worse, both in fundamental design (overload
the shell as a "is/isn't a general-purpose account" flag) and detailed
design (the interface should have been "is this shell OK?", not "give
me a list of the OK shells", since the latter works only when the list
is small and easily enumerable, thus making it infeasible to, for
example, allow an admin to configure "any shell owned by root is OK",
_even by replacing the implementation_). It's also broken
philosophically, in that it breaks the "the shell is just another
program" paradigm Unix had previously always had.
Perpetuating the mistake will not make it any less of a mistake.
/~\ The ASCII Mouse
\ / Ribbon Campaign
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Loading...