Yes:
https://github.com/SSSD/sssd/blob/master/src/tools/tools_util.h#L36

(I'm just confirming that the code checks the real ID, whether this is OK or not I'll leave for someone else..)

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Hi,

I do not understand why 'sudo sss_cache ...' isn't used here. To me this sounds like the more modern solution with better access control and auditing. So I'd prefer to not change the current behavior and will close the ticket. Feel free to reopen the ticket if using sudo does not work in your use-case.

bye,
Sumit

I am having some difficulty parsing that prior message as it appears  to speak to a different context than that of system programming in C and making system calls from a set uid program.  I do not think that comment would be relevant to this issue, and I hope you would not close the ticket based on not grocking the issue rather than based on understanding the issue and providing an explanation - though I do not think there is an explanation.  Sudo's behavior relative to zeroing out the inherited uid to zero and running as root makes it impossible to write programs to help users to do system tasks.  The inherited uid should be left as the user who started the sequence of events, so that the setuid script can know who it is working for as it does system stuff.  The current behavior also kills the audit trail, by zeroing out the inherited user id, the user who begins the mischief becomes anonymous.  -Thomas

to be more clear, to write programs to help users do system tasks, where the knowledge of who the user is is required.  That is why there is an inherited uid in addition to the effective uid.  There are workarounds, such as passing identifying information through the environment, but those work arounds are not secure, because, unlike the inherited uid, the environment may be spoofed. .. that is why the inherited uid and such identification is handled by the OS instead of the application layer, but sudo is currently defeating this mechanism.  And thus, indeed, I do  believe it is a bug.

Hi,

thanks for explaining your use case. I would recommend to use auditd do record which user is doing what with sudo, see e.g. https://sudoedit.com/log-sudo-with-auditd/.

As an example. If I set

    sudo auditctl -a exit,always -F arch=b64 -F euid=0 -F path=/usr/sbin/sss_cache -S execve -k sudo_audit

and a user with UID 1000 then calls

    date ; sudo sss_cache -E
    Thu Feb 25 14:59:56 UTC 2021

then the administrator can later call

    sudo ausearch -ua vagrant -k sudo_audit -x /usr/sbin/sss_cache

    time->Thu Feb 25 14:59:56 2021
    type=PROCTITLE msg=audit(1614265196.620:5737): proctitle=7373735F6361636865002D45
    type=PATH msg=audit(1614265196.620:5737): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=153852 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=PATH msg=audit(1614265196.620:5737): item=0 name="/sbin/sss_cache" inode=606020 dev=fd:01 mode=0104555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=CWD msg=audit(1614265196.620:5737): cwd="/home/vagrant"
    type=EXECVE msg=audit(1614265196.620:5737): argc=2 a0="sss_cache" a1="-E"
    type=SYSCALL msg=audit(1614265196.620:5737): arch=c000003e syscall=59 success=yes exit=0 a0=561aea8a88b8 a1=561aea8b0178 a2=561aea8c7160 a3=1 items=2 ppid=59080 pid=59082 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sss_cache" exe="/usr/sbin/sss_cache" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sudo_audit"

So you get full path of the command with options, execution time and 'auid=1000'



If you prefer to do this manually in scripts you can check /proc/self/loginuid, e.g.

    sudo  cat /proc/self/loginuid
    1000



I hope one of this will work for you.

bye,
Sumit

Gosh it seems that I have raised a systems program issue but am being pulled into a systems administration discussion.  I get this impression because there is no discussion about the purpose of the inherited user id, the use case code I put up on github as noted in the original approach,  or any other systems programming stuff.

For example, the work around Sumit posts just above for recovering the inherited user id is a lot of unnecessary work and probably would not be reliable or secure.  i.e. that the (formerly) short system program should go to the file system, parse a log file and in some reliably manner in a dynamic system find the exact entry corresponding to its own invocation, and then go to /etc/password and parse that file also, so as to translate a user name back to the uid. Please keep in mind, we are talking about a (formerly) short C program doing this, not a Python program, and not a human being. Being able to provably get the correct line from the log file and making sure that /etc/password is still coherent data, and perhaps another couple of end cases, are non-trivial programming problems in this context.  Wouldn't it be much better to just not zero out the 4 bytes in the first place so that they do not have to be recovered???

Surely the person who closes this bug report would be flaunting his or her understanding of the systems programming issues and explain why it was a worthwhile trade off to change the many years now conventional behavior of Unix in passing this 4 byte inherited uid register through the OS, instead of to going to the file system while solving a relatively complex parsing problem.  Where is the advantage in forcing this new situation?

Anyway, what is it to me? I can just patch the binary to not zero out the register if need be.  I just thought someone would appreciate the issue being raised, if nothing else, then for a good systems programming discussion and a better understand of Linux personality.