https://bugzilla.redhat.com/show_bug.cgi?id=1676961
--- Comment #9 from Thomas Walker Lynch thomas.walker.lynch@gmail.com ---
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.
sssd-maintainers@lists.fedoraproject.org