The real user ID and real group ID of a process identify who we really are. These two fields are taken from our entry in the password file when we log in. Normally, these values don’t change during a login session, although there are ways for a superuser process to change them

Can a superuser process change the real user ID and real group ID of a process, so that the relation between the real user ID and real group ID doesn't match those in the password file? For example, if user Tim isn't a member of group ocean per the password file, can a superuser process change the real user ID and real group ID of a process to be Tim and ocean respectively?

  • 5
    One important clarification here: a process running with superuser privileges has the ability of changing its own UID and GID, not those of another process.
    – filbranden
    Sep 3, 2018 at 22:28
  • Helpful - stackoverflow.com/questions/8499296/….
    – slm
    Sep 3, 2018 at 22:47
  • 1
    User Info database is purely userland. Kernel only cares about UID and GID, not the user or group database. Dec 22, 2018 at 12:02

4 Answers 4


Yes, a superuser process can change its real user ID and real group ID to any value it desires. The values in /etc/passwd and /etc/shadow are the configuration for what values should be set, but not a limitation of possible values.

Edit #1

It means programs like login will read the values from the files, so the files are configuration files or input files. They are not constraints on what a program can do. A superuser process can pass any value to the kernel, and the kernel will not check any files.

A program could call

setgid (54321);
setuid (12345);

and this would work, even if neither of the id's are mentioned in any file.


The password file and group file is not read, they are only read by the login process, to set real user id, and real group id.

There is nothing in the kernel mentioning these files. Login has to open the files, process them and set the two IDs. It could be written differently to get these IDs from somewhere else. E.g. from a networked database.

Any process with capability CAP_SETUID can set these IDs, root has this capability.

The security model in Unix, is part implemented in the kernel, and part implemented in process that run with elevated capabilities (e.g. as root).

Note that /etc/passwd and /etc/group are also read by ls, ps and any other program that needs to translate user/group names to/from user/group IDs. (They may do this through a library, than knows about alternative methods of storing these details.)

  • 1
    They (/etc/passwd, /etc/groups) are also read by processes which want to show or process user names instead of the internal numeric IDs, e.g. ps and ls. Sep 4, 2018 at 8:10

Among other things, the purpose of /etc/passwd is to translate a user's name to a user's UID. If you don't care what bob's UID is, you don't need that file. If you just want to change to an arbitrary UID/GID, use the relevant syscalls:

int setuid(uid_t uid);
int setgid(gid_t gid);

Note that a privileged process with the CAP_SETUID and CAP_SETGID capabilities (which a root process generally has) can only change its own UID and GID, not that of another running process.


I have recently created a Linux kernel module to do that (https://github.com/xuancong84/chown-pid ). So far, no user-level program can do that.

You need to build the kernel module, cd into the project folder and run make. If successful, it will produce chown-pid.ko.


insmod chown-pid.ko arg_pid=<PID> arg_gid=<UID> arg_act='set_uid' && rmmod chown-pid
insmod chown-pid.ko arg_pid=<PID> arg_gid=<GID> arg_act='set_gid' && rmmod chown-pid

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .