Fred Cohen 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.
rename() call overwrites (well, unlinks) destination if is is already
there. (This one was surprizing to me) With this, one rename can be
as atomic as possible by this system (in filesystem like tux2 it should
be absolutely safe). So:
create and write new file /etc/npasswd
link current to backup /etc/passwd and /etc/opasswd
(here we have two links!)
rename new to current (atomic unlink + rename here)
It is up to kernel/fs/etc to deal with this the best it can do.
> 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.
There is `vipw' command in [linux] shadow utils available exactly for
this
purpose.
> 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?
This is exactly why lckpwdf() routine was introduced (don't know by whom
and when) -- so that all applications can use it.
> 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
What else files should be handled this way? Why only /etc/passwd?
Why not kerberos databases for example?
> 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.
See above -- "atomic" rename(2).
> 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.
That are mostly not a bugs, but incompatibles. And ssh (at least
openssh)
actually _can_ use both shadow and md5 -- it uses PAM.
> FC
>
Regards,
Michael.
