In message <slrnavap6e.ip.apost@water.amer.interwoven.com>, Alan Post writes:
>
>Currently the utilities for changing /etc/passwd are setuid root.
>
>A different "user database" format could, I believe, avoid that need
>by putting user-settable fields in files owned by that user.
>
>Specifically, I propose the following directory tree:
>
>  drwxr-xr-x  root:wheel   /etc/userdb
>  dr-xr-xr-x  root:wheel   /etc/userdb/apost
>  -r--r--r--  root:wheel   /etc/userdb/apost/uid
>  -r--r--r--  root:wheel   /etc/userdb/apost/gid
>  -rw-------  apost:users  /etc/userdb/apost/passwd_hash
>  -rw-r--r--  apost:users  /etc/userdb/apost/office
>  -rw-r--r--  apost:users  /etc/userdb/apost/homedir
>  -rw-r--r--  apost:users  /etc/userdb/apost/shell
>  dr-xr-xr-x  root:wheel   /etc/userdb/otheruser
>
>and so on.
>
>The advantages of this include:
>
>  1)  remove setuid root bit on relevant programs
>  2)  remove need for string escaping/parsing
>  3)  let the kernel protect the username->uid mapping, using a
>      simple, clear application of filesystem rules
>
>The only disadvantage that I can come up with is that if I am able to
>impersonate a user, I can set her password without knowing the current
>one.
>
>Am I missing something basic?

Yes -- the changes you're permitting are root-equivalent, which means 
that only root should be able to do them.  For example, if I can change 
your home directory, I change what .profile you use, which means I 
could run any commands as you.  Similarly, I could change your hashed 
password to one I know the plaintext for, which means that again, I'd 
have access to all your files.

I don't have a hack yet for the "office" field, but switching to a new 
database just for that doesn't seem worth it to me.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)