Apparently Fred Cohen <fc@all.net> wrote:
>> This IS a point. User's database is very sensitive data, if you
>> lost it, you will not be able to login/use your system.
>> Renames is more-or-less quick operation, compared to series of
>> read/writes on potentially big files. Two renames still dangerous,
>> especially if we will be interrupted between 'em. But I think
>> that it is better than read/writes.
> My preference would be that there are two files linked to the password
> name rather than none if the system should fail at the wrong time - one
> old and one new. The problem here is basically that there is no atomic
> swap operation - for memory locaitons or file systems. If there is more
> than one program that modifies /etc/passwd, I would prefer that there be
> one authorized method for modification - built into the kernel perhaps -
> that is accessed by all of them. They can try whatever they like, but
> only one kernel call allows the file to be written - and that call takes
> the parameters for the file content and does the modification.
> OK so this will not happen - and frankly, I like being able to edit my
> password file manually at runtime with users logging in and changing
> their passwords all the while. But at a minimum, could we all agree one
> one mechanism or the other, alter all the code that uses the other and
> move on?
We don't need another kernel function (system call). This can be
done just fine in userspace.
> As a side issue, how about an OS feature that looks for the /etc/passwd
> file AND IF IT IS NOT THERE looks for /etc/passwd.old and uses it. In
> this way we have the built-in backup of the last version of /etc/passwd
> and the 'copy - modify - move' thing becomes close enough to atomic for
> the required reliability.
That OS feature is already be there. It's called your rc scripts.
You can add your own check in /etc/rc.sysinit or /etc/brc or
/etc/bcheckrc or whatever your system calls it. I think something
like:
grep -q "^root:x:0:0:root:/root:/bin/bash" /etc/passwd \
|| cp /etc/passwd- /etc/passwd
... would be a start (assuming that you use shadow passwords).
On my Linux systems I have a pwck command. That will perform a
set of consistency checks on my passwd (and group) files and
returns an error if any inconsistencies are found. (It should be
a standard part of the shadow utilities suite). So it might
make sense to run pwck during boot, copy in your backup if
that returns an error. (You might want to re-run pwck command
after the copy, in case the backup copy is also damaged -- and
you can have an immutable copy of the "last ditch" passwd/group
files held in final reserve. Of course you can also create your
"last ditch" passwd file with a redirected echo command if all else
fails).
> As an aside - and since nobody has yet answered this one - the
> mechanisms for authentication in place today have some bugs that screw
> things up severely when a password file is copied from one system to
> another. Changes fail - some authentication failes - ssh cannot use
> the MD5 or shadow passwords - etc.
> FC
Clearly all of the programs which attempt to do authentication and/or
any form of modification of or manipulation of the user accounting
information on a system should all be using the same set of
library calls in a compatible way. Thus they should be using
getpwent(), setpwent(), and crypt(). These library functions should
be handling all of the local system semantics.
Of course PAM is supposed to make this extensible --- however I
haven't see a really good description of how programs should use PAM.
As long as my program can assume that it is talking to an interactive
terminal device or windowing system PAM makes sense. When it comes
to services where there is not option for interactivity PAM's
extensibility is somewhat more limited.
Overall I'd say that FreeBSD kicked Linux butt years ago with their
authentication suite. Shadow with optional MD5 support, and S/Key
(OPIE) has worked there forever.
As for the "tranportability" of passwd entries:
I would say that it's best to unshadow (temporarily) your passwd
file to prepare "portable versions" which can be copied to other
systems. As for MD5 vs. DES hashing (vs. SHA-1 "Big-DES" etc)
--- that is not a reasonably soluable problem. You can either
stick with DES (supported on all UNIX systems, as far as I know)
or you can require that all of *your* UNIX platforms support the
other hashing algorithms that you wish to use in these "portable
passwd entries."
--
Jim Dennis Technical Research Analyst Linuxcare, Inc.
jimd@linuxcare.com, http://www.linuxcare.com/
415 505-9306 415 701-7457 fax
Linuxcare: Support for the Revolution
