11

Trying to learn about UIDs and GIDs.
Various online reading led me to believe that my UID is saved in /etc/passwd, but this doesn't appear to be the case on a server where I work:

$ whoami
user1
$ cat /etc/passwd | grep user1
$

Is there a(nother) file besides /etc/passwd that could contain my UID?

(I'm assuming UID is similar to GID in that there is a file somewhere that contains it. I've found the GID I'm interested in in the file /etc/group)

I know that I can get my UID with the command id -u, but for this question, I'm specifically interested in learning whether there's a file that contains it.

StoneThrow
  • 1,575
  • 5
  • 19
  • 41
  • 9
    Is this your personal system, or some university machine? If the latter, they could be using LDAP or AD. – muru May 12 '22 at 05:00
  • 6
    If possible, always use `getent passwd` instead of trying to parse the password database directly. It uses the same libc functions that the rest of the system does, so it will show you what everything else _actually_ sees, not just what’s in the local password file. – Austin Hemmelgarn May 12 '22 at 17:06
  • 1
    As an aside, `grep` can take a file name as an argument, so you never need to do `cat file | grep pattern` and can always just do `grep pattern file` or `< file grep pattern` and similar constructs avoiding an extra command. – terdon May 13 '22 at 12:33
  • @muru - it's a work PC. I think you are correct that it's LDAP or AD because when I `ls` files created by `user1`, the owning group is "`domain users`". Some experimentation led me to learn that group names containing space characters are illegal -- so I assume the group could not have been created "natively" in Linux? Other reading led me to some association between that specific group "`domain user`" and LDAP/AD, but I don't completely understand what either of those are. – StoneThrow May 13 '22 at 15:13
  • 1
    LDAP servers are kinda like network databases (or "directories") typically used for account management. So instead of maintaining the same users and UIDs and groups and GIDs in the `passwd`/`group` files on a bunch of systems, you maintain them in the LDAP server and configure those systems to use those servers to obtain account data. LDAP is a protocol, there are many implementations (e.g. OpenLDAP is fairly popular). Active Directory (AD) is Microsoft's. – muru May 13 '22 at 15:50
  • 1
    Also yes, having spaces in the group name is a sure indication of AD. People running Unix-y LDAP solutions wouldn't allow such weirdnesses. – muru May 13 '22 at 15:52

2 Answers2

22

Yes /etc/passwd is one of many ways the user account database can be stored and queried.

In many Unix-like systems, the Name Service Switch (initially from Solaris) is responsible for translating some system names to/from ids using a number of methods.

Its configuration is usually stored in /etc/nsswitch.conf.

In there, you'll find entries for a number of databases and how they are handled (group, passwd, services, hosts, networks...). For the hosts database which is used to translate host names to network protocol addresses, you'll find that DNS and sometimes mDNS are generally queried in addition to /etc/hosts.

When a process requests information about a user name such as with the getpwnam() standard function, the methods to use are looked up in that file for the passwd entry.

If such a method is the files method, /etc/<db> will be looked up. On GNU systems, that's typically done by some /lib/<system>/libnss_files.so.<version> dynamically loaded module.

But you can have many more, such as NIS+, LDAP, SQL. Some of those methods are included with the GNU libc, some can be installed separately. On Debian or derivatives, see the output of apt-cache search 'NSS module' for instance.

In enterprise environments, where the user database is centralised, the most popular central DB was NIS, then NIS+ while these days, it's rather LDAP or Microsoft's Active Directory (or its clones for Unix).

If present, the get{pw/host/grp}...() functions of the GNU libc will also query a name service caching daemon via /run/nscd/socket instead of invoking the whole NSS stack and query the backend DBs directly. Then the querying will be done by nscd and cached to speed up later queries. Some NSS modules can can also do their caching themselves.

On GNU/Linux systems, a popular method is using System Security Services (sss). That comes with a separate daemon (sssd) that handles the requests and despatches them to other databases (such as LDAP / AD) while also doing some caching. Then /etc/nsswitch.conf will have a sss method for most DBs, and the backends are configured in the sssd configuration. PAM (responsible for authentication) also typically queries sssd in that case.

That should help clarify why querying /etc/passwd (or /etc/group or /etc/hosts...) to get account (or group/host...) information from the command line is wrong in the general case. Most modern systems will have a getent command instead for that (also from Solaris), or more portably, you can use perl's interface to all the standard get<db>*() functions.

$ getent passwd bin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
$ perl -le 'print for getpwnam("bin")'
bin
x
2
2


bin
/bin
/usr/sbin/nologin

$ getent services domain
domain                53/tcp
$ perl -le 'print for getservbyname("domain", "tcp")'
domain

53
tcp
$ perl -le 'print for getservbyname("domain", "udp")'
domain

53
udp
Stéphane Chazelas
  • 522,931
  • 91
  • 1,010
  • 1,501
  • 5
    @StoneThrow and on such system there's the command `getent` that will use those glibc functions. Eg: instead of `cat /etc/passwd | grep user1` use `getent passwd user1` that will also query other configured databases. – A.B May 12 '22 at 05:45
  • 1
    @PhilipCouling Actually, macOS is the strange one here. NSS was a SunOS (and later Solaris) thing originally, and got reimplemented in a near identical form on AIX, IRIX, HP-UX, multiple BSD variants, and Linux. Additionally, on Alpine Linux you actually can use it, you just need some extra components that aren’t part of the default install (also, Alpine uses musl, not uClibc). – Austin Hemmelgarn May 12 '22 at 17:12
1

technically yes there is some file somewhere that contains the uid for every given username.

If you make simple local accounts in linux then it would be in /etc/passwd in field #3 between the :'s.

But if linux uses ActiveDirectory authentication then it would get all the username/uid info from another server, and then is that stored in some [text] file on your linux system I don't know, it might just be stored in memory; I would be very interested in knowing this detail.

There are a few login or authentication schemes that linux supports, AD for one, also LDAP. Where LDAP stores the username and uid mapping I do not know, but I would also be interested in knowing.

So... Is there a file besides /etc/passwd that contains/defines my UID? yes. It depends on all the different login/authentication methods linux supports, besides the simple traditional local /etc/passwd method and which method is being used. So your next question might be what are all the login authentication methods linux supports and how do I tell which is being used..

ron
  • 5,749
  • 7
  • 48
  • 84
  • LDAP handling depends on how the LDAP server is configured. _Usually_ it uses an RDBMS of some sort as a backend, though there are exceptions (OpenLDAP for example actually supports storing data as plain text LDIF files). – Austin Hemmelgarn May 12 '22 at 17:07