Detaching program from controlling terminal

[Matthew Seaman]

On Tue, Jun 15, 2004 at 01:44:25PM +0800, Ihsan Junaidi Ibrahim wrote:

> I'm somehow stuck in the loop now and am hoping some of you can give me 
> pointers on how to proceed. Due to a customer requirement, I need to 
> build a simple web-based (via cgi or php) script to change the system 
> password. They found that sshing to the server and typing passwd to 
> change the password is wee too involving hence the need to use a much 
> friendlier interface. Letting the sysadmins change the user's password 
> is not a good idea, as the sysadmins are outsourced and the users value 
> their privacy. FYI, all the users has a /sbin/nologin shell set. I'm 
> running FreeBSD 5.2.1.

Yes.  Sometimes customers want dumb things, and all in the name of
convenience.  There's a reason things are the way they are: security.
Changing passwords on unix is designed to be restricted to an
interactive login session deliberately.  That's because you absolutely
have to have root permissions in order to change a system password.
Making that access available over a network, or to users that haven't
authenticated themselves against the password database they want to
change is a recipe for disaster.
 
> I understand there are two primary way to change a user's password, 
> either via passwd or pw. Since pw is a root-only program, that doesn't 
> seem the best way to do it over the web so I'm left with passwd.

Yes.  Forget about using passwd(1) for this purpose: it's carefully
designed to make using it on anything other than a terminal session
difficult.  Using pw(8) is the way to go, and you will need to have
your web based session interact with a root level process that runs
pw(8) for you.  You will also need to go to great lengths to ensure
that one user cannot modify the password of another one.  That is a
great deal harder to do correctly than it sounds.

Take a look at the sysutils/webmin port for something that does
similar security-sensitive things.  Not that I recommend that
particularly as a particularly good example of how to do such things,
just as /an/ example.

> If there's something that I have missed or there's better alternatives, 
> please point it out. :)

Since you aren't allowing your users to log into your FreeBSD server
the question arises as to why exactly they need passwords there?  Two
things leap to mind immediately: access to shared filesystems or
access to an e-mail server.

File system access generally means that you need some sort of shared
password database between the server and all the client machines that
access the filesystems.  (Broadly: there are ways of organising these
things using certain networked filesystems without that, but those are
quite unusual).  Mechanisms for shared password databases include NIS
-- which works if all your clients are on Unix machines; various
Windows password systems which you can access from FreeBSD via Samba;
and LDAP which is the latest thing, and one of the core technologies
in Active Directory.  If your clients are all running Windows systems,
then tying your FreeBSD server into the Windows authentication system
(so the users can chsnge their passwords from their desktops) is
probably your best bet.

For e-mail access, the same sort of arguments apply.  You can
alternatively separate the database of e-mail accounts completely from
the system password database: the Cyrus e-mail system (in ports) works
in that way, and there are some well documented recipes on the web for
setting up such arrangements using qmail.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20040615/b43d6369/attachment.bin