[Bug 1676961] sss_cache ignores effective uid
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1676961
--- Comment #9 from Thomas Walker Lynch <thomas.walker.lynch(a)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.
--
You are receiving this mail because:
You are the assignee for the bug.
3 years, 1 month