[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: password file locking

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

	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 

> 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []