> 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? 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. 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
