Other permissions apart from filesystem access

Question

Quoted from this answer about the difference between filesystem user id and effective user id of a process, it says that

The FSUID is used for filesystem accesses, the EUID for other things.

What are these "other things"? I can only think of system calls like connecting to a socket, but besides filesystem interaction, anything else requires the process to have superuser rights as far as I know. So effective uids (and gids) I guess are pretty much pointless unless you are root.

Is anything else appart from system calls? I also know that user/group permissions affects the signals that can be send among processes but I'm not sure about how that works. Could maybe be added to the mix other kinds of interprocess communication like shared memory and such?

And also, if a user has permission to execute a certain file, executing it is considered a "filesystem permission"? Could that depend on the executable being a script (that requires the SO runs a process owned by the user that read the script line by line, and thus implies a filesystem read operation), or a binary (the file contents are directly copy-pasted to the RAM by the SO I guess)? And what if a file has execute but not read permission (for both, binary or textual executable)?

Answer 1

The effective IDs are used for a range of purposes.

Signal sending, as described in kill(2):

   For  a process to have permission to send a signal, it must either
   be privileged (under Linux: have the CAP_KILL  capability  in  the
   user  namespace  of  the target process), or the real or effective
   user ID of the sending process must equal the real or  saved  set-
   user-ID  of  the  target process.  In the case of SIGCONT, it suf‐
   fices when the sending and receiving processes belong to the  same
   session.

When creating System V IPC objects, as described in (for example) msgctl(2):

   If a new message queue is created, then its associated data struc‐
   ture msqid_ds (see msgctl(2)) is initialized as follows:

          msg_perm.cuid  and  msg_perm.uid  are  set to the effective
          user ID of the calling process.

          msg_perm.cgid and msg_perm.gid are  set  to  the  effective
          group ID of the calling process.

When setting the process nice value, as described in setpriority(2):

   EPERM  A  process  was  located, but its effective user ID did not
          match either the effective or the real user ID of the call‐
          er,  and  was  not  privileged  (on Linux: did not have the
          CAP_SYS_NICE capability).  But see NOTES below.

Likewise, when setting CPU affinity with sched_setaffinity(2):

   EPERM  (sched_setaffinity()) The  calling  thread  does  not  have
          appropriate privileges.  The caller needs an effective user
          ID equal to the real user ID or effective user  ID  of  the
          thread   identified   by   pid,  or  it  must  possess  the
          CAP_SYS_NICE capability in the user namespace of the thread
          pid.

Other examples include the following system calls: prlimit(2) and keyctl(2).