libselinux bug or not

[William Xiong]

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?

[Steve G]

> 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

This may not be the exact answer you want...but pam is not thread safe at all. 
Not just for this reason, but because it uses functions that are known to be
unsafe in threaded apps.

-Steve

__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com

[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.