Solved What purpose does /etc/passwd serve in FreeBSD?

[puppydog]

I was needing to do some user modification yesterday and made some direct edits to /etc/password. I couldn't figure out why the changes I made there weren't reflected with pw commands and vice versa, but then I learned about master.passwd and vipw and was able to make the changes I needed to make.

So, what exactly does /etc/passwd do on FreeBSD? Is it just there as a legacy thing with no purpose?

 

[puppydog]

hm, I guess that explains it, but it still seems unnecessary to me.

 

[drhowarddrfine]

it still seems unnecessary to me.

So you think storing password information is unnecessary?

 

[puppydog]

So you think storing password information is unnecessary?

I think it's unnecessary to have the information in /etc/passwd replicated in /etc/master.passwd. The latter essentially just combines the traditional /etc/shadow and /etc/passwd files into one file, making /etc/passwd redundant, especially since you can't always rely on /etc/passwd to accurately reflect changes made to /etc/master.passwd.

 

[Datapanic]

If you don't want local storage of passwords on a server, use LDAP!

 

[Deleted member 45312]

You should use vipw(8) to edit /etc/passwd

 

[drhowarddrfine]

There is a reason for having both /etc/passwd and /etc/master.passwd which I can't explain now.

 

[Jose]

Traditionally, each line in /etc/passwd consists of seven fields; the second field contains a string that represents the user's encrypted password. Since /etc/passwd must be world-readable for commands like ls to work, the encrypted password string is available to all users on the system. Evildoers can encrypt selected dictionaries or words and compare the results with the strings in /etc/passwd. If the encrypted strings match, a password has been found.

Nemeth, Snyder, Seebass, and Hein: UNIX System Administration Handbook, second edition, page 543.

 

[Kai Burghardt]

I think it's unnecessary to have the information in /etc/passwd replicated in /etc/master.passwd.

It’s supposed to be the other way round: ? Data in /etc/master.passwd is replicated in /etc/passwd except passwords being stripped.​

The latter essentially just combines the traditional /etc/shadow and /etc/passwd files into one file, […]

Wikipedia claims shadow was UNIX and Linux, ? master.passwd was BSD. passwd(5) first mentioned master.passwd in FreeBSD version 2.1.0 (released 1995‑11‑19). ? Apparently before that FreeBSD did not employ password shadowing at all.​

So, what exactly does /etc/passwd do on FreeBSD? Is it just there as a legacy thing with no purpose?

Yeah, kind of, but not necessarily.​

• getent passwd respects nsswitch.conf(5). In environments with centrally‑managed user accounts this may output bazillions of lines. ​
• If you just want to learn about local users, but you (cannot or) do not want to (indirectly) use db(3) to read /etc/pwd.db, the plaintext /etc/passwd is quite convenient. ?​

I guess it’s also a bit of a backward-compatibility thing: Earlier today I noticed sysctl(8) still accepts (and now ignores) a -w flag that has been removed in 4.4 (23 years ago). ? There’s no real harm in supporting some legacy stuff to some degree. “If it ain’t broke don’t fix it.”​

If you don't want local storage of passwords on a server, use LDAP!

NIS (ypserv(8)) and Kerberos (kdc(8)) are part of the base system. ?‍ I like NIS because it’s super easy in comparison to Kerberos. However, ypserv(8) does not support any encryption, so it’s really only OK for completely trustworthy networks.​

You should use vipw(8) to edit /etc/passwd

You shouldn’t manually edit passwd at all, but if you must use vipw(8). ? I think the NIS stanzas like +::::::::: cannot be added/edited with pw(8) (should they even be necessary), so that’s a use case for vipw(8).​

[…] Since /etc/passwd must be world-readable for commands like ls to work, […]

Huh, what? OK, yeah, for humans you want to resolve numeric user/group IDs to a textual user/group ID. It’s a bit weird to say ls(1) cannot run without the world‑readable bit of /etc/passwd’s filemode being set. ? Maybe it’s a wording amended since.

I understand this is a 1995 book on UNIX, but with respect to FreeBSD’s implementation ls(1) uses user_from_uid(3) → getpwuid(3) → nsdispatch(3) → … → (assuming nsswitch.conf(5) includes the files backend) files_passwd → pwdbopen which consults and only consults /etc/pwd.db. ? Temporarily (re‑)move /etc/pwd.db and ls(1) lists numeric IDs only (unless user_from_uid(3) cached them). None of the functions bother to read /etc/passwd as a fallback.​

 

[Jose]

I understand this is a 1995 book on UNIX...​

So? It's good to know why we wound up with two files in the first place. In any case, the current situation still matches what they wrote:

$ ls -l /etc/passwd 
-rw-r--r--  1 root  wheel  2360 May  5 14:13 /etc/passwd
$ ls -l /etc/master.passwd 
-rw-------  1 root  wheel  2760 May  5 14:13 /etc/master.passwd

BTW, /etc/pwd.db is built from /etc/master.passwd using pwd_mkdb(8). I ran into this thread recently when I discovered my /etc/master.passwd had ISO-8859-1 characters in it, and they were causing vipw(8) to barf.

The root of the original problem is that the design of /etc/passwd violates the principle of do just one thing and do it well. It contains both authentication credentials and user metadata.

 

[bakul]

BTW, /etc/pwd.db is built from /etc/master.passwd using pwd_mkdb(8).

spwd.db, not pwd.db, is built from master.passwd.

The root of the original problem is that the design of /etc/passwd violates the principle of do just one thing and do it well. It contains both authentication credentials and user metadata.

You can't really escape this. Both auth credentials as well as non-credential metadata need uid as the key. While very few commands/libraries need access to the first, a lot of programs need access to the second. What is more, Unix has always provided databases as text (termcap etc) which scale fine up to a few tens of entries. As long as you realize that master.passwd is the original and the other three are derived from it, there is no confusion.

 

[Jose]

spwd.db, not pwd.db, is built from master.passwd.

I just read the man page again, and it clearly states both are built from master.passwd. Am I missing something?

 

[bakul]

You're right. Apologies.

[Edit] I ran pwd_mkdb under ktrace. It seems to be generating passwd file as well. So my guess is pwd.db is generated from this new passwd file, while spwd.db is generated from master.passwd. So technically I may be right too