Subject: pkg/27162: pkgsrc creates an inadequate /etc/shells if it doesn't
To: None <>
From: Gavan Fantom <>
List: tech-pkg
Date: 10/08/2004 12:51:08
Hi folks,

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