[redhat-lspp] Re: some additional pam_namespace issues ..

[JANAK DESAI]

Stephen Smalley wrote:

>On Thu, 2006-02-16 at 12:10 -0500, JANAK DESAI wrote:
>  
>
>>I have unit tested this and it works well. Does anyone see any
>>issues in getting to the original directory in this manner?
>>    
>>
>
>Not offhand.
>
>  
>
>>The second is a question regarding su/getexeccon/getcon..
>>The pam_namespace module uses pam session management
>>hooks to create polyinstantiation instance directory based on
>>the context returned by getexeccon. Since su no longer
>>uses pam_selinux (which does a setexeccon), getexeccon
>>in pam_namespace returns null. I am wondering if it is
>>ok to use getcon() when getexeccon() returns null (indicating
>>default policy behavior for the context of the next execed
>>process)? If I use getcon(), su will re-polyinstantiate based
>>on the correct new user id and the correct mls range,
>>however the domain name used in instance directory
>>will not reflect the domain of the shell executed by su.
>>However, since we do not re-polyinstantiate on domain
>>transitions through execs anyway, I am guessing using
>>getcon() is acceptable. Thoughts?
>>    
>>
>
>Not sure I follow.  Since we are no longer changing contexts via su, why
>do we care about computing any context for the polyinstantiation?  We
>should only care about per-user polyinstantiation, which doesn't depend
>on SELinux context at all there.
>
>  
>
With the current implementation, you can specify if the directory should be
polyinstantiated based on user, context or both. The config file does 
not make
any distinction on which program may be trying to polyinstantiate. So if
I have setup /tmp to polyinstantiate based on both user and context, both
login and su will use that setup. The namespace module tries to compute
the type-member if the polyinstantiation method involves context and
doesn't differentiate if it was called from login or su. I will check to 
see if
there is a way to easily identify the calling program.

Thanks.

-Janak