Subject: pkg/27162: pkgsrc creates an inadequate /etc/shells if it doesn't
To: None <firstname.lastname@example.org>
From: Gavan Fantom <email@example.com>
Date: 10/08/2004 12:51:08
I'm looking for ideas on how best to deal with /etc/shells if it doesn't
already exist. (See PR pkg/27162) What we do currently is to create a new
/etc/shells containing just the shell being installed.
This causes problems on any systems which don't have a default
/etc/shells, and where the administrater has not created one. NetBSD
ships with a default /etc/shells, but other systems, such as Solaris, do
In the absence of /etc/shells, a system will typically behave as if a
default set of shells were listed. This default set of shells is provided
by the getusershell(3) function.
There are some obvious possibilities here:
* Stick with the status quo. This bites on Solaris, where installing any
shell from pkgsrc will cause all users to be denied login by dtlogin.
* Not update /etc/shells if it's not present. This is easy to do, but
leaves users of the shells installed from pkgsrc unable to log in without
intervention from the administrator.
* Write a C program to use getusershell(3) to iterate the default set and
generate a "default" /etc/shells on demand if it is not present. This
would be a pain from a package's install script, and so would probably
require a separate package as a dependency.
* Extract the default list by other means, such as parsing the
getusershell(3) manpage (ugh!)
I think the third option is probably the best so far, but I worry about
what happens in a NIS environment where getusershells(3) could go off and
retrieve a remote database. Do we need to worry about this scenario? Does
it even make sense to try to DTRT here?
Does anybody have any better suggestions, or any pros/cons/votes for any
of the above possibilities?
Gillette - the best a man can forget