chore: Use geteuid() instead of getuid() to check privilege

[ruihe774]

I believe the correct way is to check geteuid() == 0, not getuid() == 0.

[openshift-ci]

Hi @ruihe774. Thanks for your PR.

I'm waiting for a ostreedev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ericcurtin]

This looks correct to me, I tend to favour geteuid over getuid, most of the time that's what people actually want to do. But I'm not sure about every little use-case of OSTree.

What I will say, was there actually a bug or defect found here, etc.?

Or are we just changing for the sake of it because geteuid is the "better" one that's a more true test of rootness?

[ruihe774]

What I will say, was there actually a bug or defect found here, etc.?

Not appeared. But it is easy to produce one. You can set the SUID bit of a program using libostree (e.g. ostree itself). In a program that gains privilege by SUID, getuid() returns the user that invokes the program, and geteuid() returns 0.

[cgwalters]

No one should be including libostree in a setuid binary.
(Really there should be no setuid binaries at all, but that's another thing)

[cgwalters]

/ok-to-test

[ruihe774]

No one should be including libostree in a setuid binary. (Really there should be no setuid binaries at all, but that's another thing)

Yes. However, processes can drop privileges temporarily using seteuid() as well. In this case, getuid() returns 0 and geteuid() returns a unprivileged uid.

[cgwalters]

Yes. However, processes can drop privileges temporarily using seteuid() as well. In this case, getuid() returns 0 and geteuid() returns a unprivileged uid.

Yeah, though that kind of thing I personally consider a bad idea because most modern codebases are multithreaded, and changing uid affects all threads, which can have surprising effects. Basically if you do this type of thing you should fork off a dedicated helper process which runs always as that uid from the start - and that process shouldn't be doing anything related to ostree in general.

[cgwalters]

/override continuous-integration/jenkins/pr-merge

[openshift-ci]

@cgwalters: Overrode contexts on behalf of cgwalters: continuous-integration/jenkins/pr-merge

In response to this:

/override continuous-integration/jenkins/pr-merge

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ruihe774]

and changing uid affects all threads

This is implemented by libc (e.g. NPTL). If you use raw syscall (sounds tricky), changing uid affects only current thread.

[cgwalters]

If you use raw syscall, changing uid affects only current thread.

Yes, but doing raw syscalls like that last I heard from the glibc developers often means you cannot invoke any later APIs from glibc, which becomes a giant pain in the butt. I'm not sure if there's a better reference but (searches for a minute) yeah see this comment for example.