3

It's possible to change UID/GID of current process as it runs programatically with setresgid/setresuid which affects future files access rights.

However what happens to already opened or memory mapped files? Are they still accessible for i/o operations like read/write? I'm asking more in context of "not explicit" i/o operations performed by libraries, for example sqlite database or other libraries that operate on files more internally. Files opened in DIRECT_IO mode sound even more uncertain in this aspect.

Lapsio
  • 6,384
  • 4
  • 20
  • 26
  • 1
    Nothing. Would you expect an error to occur on I/O operations? That would be disasterous. What do you mean by even more uncertain? Where do you have doubts? –  Jun 19 '18 at 21:57
  • 2
    What happens when you try? That seems easy to test. – larsks Jun 19 '18 at 22:19
  • 1
    Opening handles before dropping privileges wouldn't be very useful if you could no longer use them post-drop. – Charles Duffy Jun 19 '18 at 22:24
  • 1
    ...which is to say, it's *extremely intentional* that you retain access to your file handles; if that weren't possible, a number of mechanisms for restricting daemons' privileges if compromised (while still giving them access to the content they need to work) would be broken. – Charles Duffy Jun 19 '18 at 22:32
  • 1
    For ordinary files on local filesystems, permissions don't matter after a successful open. But the rules are different for procfs files and some NFS servers. – Mark Plotnick Jun 19 '18 at 23:22

1 Answers1

3

When you open a file, your ability to do so is determined by your effective uid and gid at the time you open the file.

When you change your effective uid or gid, it has no effect on any open file descriptors that you may have.

In most cases, if you have a valid file descriptor, that's all you need to read or write the resource that descriptor is connected to. The fact that you hold the valid file descriptor is supposed to be all the proof you need that you have permission to read/write the underlying resource.

When you read or write using an ordinary file descriptor, no additional authorization checks are performed. This is partly for efficiency (because those authentication checks would be expensive to perform each time), and partly so that -- this may be exactly what you are trying to do -- you can open a privileged resource, downgrade your process's privileges, and continue to access the open resource.

Bottom line: Yes, it's entirely possible for a process to use an open file descriptor to read or write a file which (based on its current uid/gid) it would not be able to open.

Footnote: What I've said is true for ordinary Unix file descriptors connected to ordinary resources (files, devices, pipes, network streams, etc.). But as @Mark Plotnick reminds in a comment, some file descriptors and underlying resources are "different" -- NFS and Linux /proc files are two examples. For those, it's possible for additional checks to be performed at the time of read/write.

Steve Summit
  • 45,437
  • 7
  • 70
  • 103