Who would have thought that this question would drag out such a collection of overconfident and underinformed responses!
The file system uid or fsuid is a Linux feature designed to help the NFS server implementation. It is an extra (non-POSIX) uid which is used only for file permission checks. For any process that doesn't call setfsuid (basically any process that's not trying to be an NFS server), the fsuid is the same as the effective uid.
There's even a man page for it, so excuse for claiming it doesn't exist.
Update: I was inspired to go find the origin of fsuid. When it was added in Linux 1.1.44, this comment was put above the new sys_setfsuid function:
+/*
+ * "setfsuid()" sets the fsuid - the uid used for filesystem checks. This
+ * is used for "access()" and for the NFS daemon (letting nfsd stay at
+ * whatever uid it wants to). It normally shadows "euid", except when
+ * explicitly set by setfsuid() or for access..
+ */
and this change was made in the comment above sys_access:
- * XXX we should use the real ids for checking _all_ components of the
- * path. Now we only use them for the final component of the path.
+ * access() needs to use the real uid/gid, not the effective uid/gid.
+ * We do this by temporarily setting fsuid/fsgid to the wanted values
So NFS was one of the original two purposes. The other was making access() work correctly. access() is used by setuid programs to determine whether the real user would have access to a file without the additional privileges of the setuid. Before 1.1.44 it was buggy. Since then, it's been using a temporary change of fsuid to do the work. Since the fsuid is restored before the access() system call returns, you'll never actually see the change from userspace.
OK, I did a lot of extensive research and I found out what was wrong. Let's start one by one:
- When we use
initramfs boot scheme the first process which the kernel invokes is the /init script. The kernel will never try to execute /sbin/init directly.
/init is assigned process identifier 1. This is very important!- The problem now is that
/sbin/init can only be started as PID 1 but we are already running /init as PID 1.
- The solution is to execute the command line
exec /sbin/init while we are still inside /init. In this way the new process (which is /sbin/init) will inherit the PID from its parent (/init with PID 1) and that's all we have to do.
The problem I experienced with my initial configuration (see the question) was due to the fact that the last thing my /init script does is to spawn new /bin/sh process which is assigned brand new PID. From this point it's impossible to run /sbin/init directly from interactive console because even when we execute the command line exec /sbin/init, the best we achieve is to assign the same PID which has already been assigned to the shell and this PID is definitely not PID 1.
Long story short - execute the command line exec /sbin/init directly from /init and that's all.
Best Answer
For the kernel, a user or a group are just a number (the UID and GID) attached to a process and which are used to see if the process is allowed to e.g. read (really open(2)) a file (files carry UID/GID and permission bits around for this very purpose), and also other operations (e.g., processes can manipulate processes belonging to the same UID). There are system calls to change UID/GID of the calling process (setuid(2)/setgid(2) and friends). Obviously, there are severe restrictions on who can use them.
The system can use the numbers to look up names from /etc/passwd, /etc/group or a slew of other mechanisms (LDAP, NIS, others), but that is strictly for human consumption.
When you log in and give your username, a program (running as root, and so alowed to do a lot of things normal users aren't allowed) takes the username and looks up the UID (to see if that user exists in the first place), asks for the password (or some other authentication) and checks it. If all goes well, the program changes to that UID/GID and exec(2)s the user's shell (which again is just a run-of-the-mill program, exactly which one to start is part of the user's account description).