Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 6 down vote favorite

Is it possible to change password database file(/etc/passwd) to some other file. How does this authentication mechanism work internally ? Does it depend on pam ?

share|improve this question
4  
Just want to point out that despite its name, /etc/passwd does not in fact contain the actual passwords or even the hashes -- shadowed passwords have been a de facto standard since before I started using unix two decades ago. – Shadur Jul 3 '12 at 13:38

4 Answers

up vote 7 down vote accepted

You're right: /etc/passwd and /etc/shadow are consulted by pam_unix.so, which are part of PAM. At least on modern Linuxes. You could change this by patching pam_unix.so. If the manpage is to be believed, you can't change the location of the system databases.

And you really don't want to. /etc/passwd isn't just used for authentication, it's also used for (reverse) name resolution and to look up things like the user's full name, shell, et cetera. The name and location are so standardised that moving them would almost definitely break things outside of just PAM. You'd have to patch a lot more than you bargained for.

Update: If you're trying to hide the /etc/{passwd,shadow,group} files for security, don't worry about it. Security by obscurity rarely helps as a policy. Leave them where they are and tighten the rest of your policies.

Update: a possible solution

If you have some custom software you need to access a different set of user/group databases, you could make a copy of the relevant PAM and NSS modules and patch them to use your custom databases. The original unix databases stay where they are so software isn't confused, but you can set PAM and NSS to use your custom modules wherever you need to and using whatever policy makes sense to you.

Keep the unix databases essentially pristine and you have what you asked for. This is pretty much what the radius and ldap PAM/NSS modules do: they provide an additional (not replacement) source of credentials and user/group information.

Going one step further: you can go back to PAM and NSS and disable the unix database lookups altogether. Leave the files there for old software (naturally, their views of the user/group databases will be inaccurate, but at least they won't break).

share|improve this answer
1  
Name resolution and uid:name matching are being done by nss subsytem, which is also modular (=easy hackable). But you are partially right with it - it may break some scripts that read /etc/passwd directly instead of using libnss. – rvs Jul 3 '12 at 12:22
1  
The modularity is welcome but immaterial: it means you have more code to patch, and a lot of software (especially older code) might go straight to the files. This makes for a pretty nasty worst-case scenario. – Alexios Jul 3 '12 at 13:35
It can also be handled by the older shadow, as not everyone is forced to use pam yet. – lynxlynxlynx Jul 3 '12 at 17:42
up vote 2 down vote

I'm not sure if it's possible out of the box, but It's definitely possible with some hacking. In order to do this you'll need to:

  1. Tune/hack nsswitch library (/lib/libnss_files.so or libnss_db.so - check your /etc/nsswitch.conf) so it would read some other file.
  2. Tune/hack pam_unix module so it would read some other files.
share|improve this answer
5  
3. spend the rest of that system's lifetime dealing with the occasional breakage of random other stuff that expects /etc/passwd to exist... – Shadur Jul 3 '12 at 13:36
up vote 1 down vote

What you're looking for is the pam_pwdfile module. On Debian/Ubuntu the package is libpam-pwdfile (not sure about RedHat derived distros).

The README included with the package explains how to use it.

share|improve this answer
up vote 1 down vote

Use NIS or LDAP to authenticate your users. Their passwords won't be stored in the /etc/{password/shadow} file(s).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.