libselinux bug or not

[Stephen Smalley]

On Fri, 2006-01-06 at 16:20 +0000, William Xiong wrote: 
> when I use pam system to program, I invoke
> pam_chauthtok function to change passwd, If I put this piece of code in
> the main thread of a process, then everything is ok, but if i put the
> code into a child thread, then it will return failed status.
> 
> when i trace the code, I found the pam system use selinux, the pam
> system will invoke setfscreatecon() function. the implemention of
> setfscreatecon() use below code to change fscreate stat:
> 
> fd = open("/proc/self/attr/fscreate", O_RDWR);
> 
> but, if the thread invode setfscreatecon() is a child thread in a
> process, then, the /proc/self will point the main thread of the process,
> not the child thread's own proc subdir. then the following code will fail.
> 
> can some find the same problem?

Hi,

Yes, the libselinux functions presently don't allow for a child thread
to modify its process security attributes.  The change in structure
of /proc and meaning of /proc/self occurred very late in Linux 2.5
(actually in 2.6.0-test, IIRC).  We could possibly alter libselinux to
instead access /proc/self/task/<tid>/attr/... for the fscreate attribute
(security label to apply to newly created files by the thread), although
it wouldn't make much sense to do so for the exec attribute, and it
isn't permitted for the current attribute to differ among threads since
they share memory.  However, before doing so, we would need a concrete
justification, and it sounds like pam isn't thread-safe anyway according
to Steve G's posting.

-- 
Stephen Smalley
National Security Agency