Bug 443961

Summary: pams (authlogin system module) objects in /var/run/sudo
Product: [Fedora] Fedora Reporter: Dominick Grift <domg444>
Component: selinux-policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: jkubin
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-25 08:39:44 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Dominick Grift 2008-04-24 08:36:43 EDT
Description of problem:

Yesterday i played around with the sudo & selinux things.
Today i was confronted with a AVC denial related:

type=AVC msg=audit(1209003070.843:101): avc:  denied  { getattr } for  pid=25679
comm="updatedb" path="/var/run/sudo/dgrift2" dev=dm-1 ino=1490991
scontext=system_u:system_r:locate_t:s0-s0:c0.c1023
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir

And so i wondered what could have caused it.

I have not figured that out yet but upon inspection of the authlogin system
module i found this related to pams objects in /var/run/sudo:

delete_files_pattern(pam_t,pam_var_run_t,pam_var_run_t)
read_files_pattern(pam_t,pam_var_run_t,pam_var_run_t)
files_list_pids(pam_t)

This has me wondering; should pam not be able to manage it's objects there?

manage_files_pattern(pam_t,pam_var_run_t,pam_var_run_t)
manage_dirs_pattern(pam_t,pam_var_run_t,pam_var_run_t)
files_list_pids(pam_t)

Also it apears these locations do not get cleaned up when user accounts are deleted.
Comment 1 Daniel Walsh 2008-04-24 14:07:23 EDT
This looks like a labeled directory suddenly became unlabeled.   Did you load
and unload a policy module?

Were you changing semanage

restorecon -R -v /var/run/sudo will fix.

Comment 2 Dominick Grift 2008-04-25 06:24:56 EDT
I did not load or unload any policy. i removed that user. dgrift2. (userdel -r
dgrift2)
should pam not manage its content in /var/run/sudo? (e.g. remove unused directories

that user /var/run/sudo/dgrift2 did no longer exist on the system. but the
directory was still there. (unlabeled_t)

i know restorecon fixes it. i cannot restorecon /var/run/sudo every time i
remove a admin user from my system 

but i am wondering: if pam owns that dir , than why doesnt it manage/maintain it
and why does selinux not allow pam to manage its objects.

i dont think this is a selinux issue after thinking about this. I think pam 
does not maintain its objects properly. i think that if pam would delete those
unused old directories in /var/run/sudo that there would be policy to allow this.

but since pam just leaves on /var/run/sudo/* objects it makes /var/run/sudo a
bit messy and maybe thats also the reason why some objects thee get unlabeled_t




Comment 3 Daniel Walsh 2008-04-25 07:10:38 EDT
What does getfattr say the label is?

getfattr -n security.selinux /var/run/sudo/dgrift2
getfattr: Removing leading '/' from absolute path names
# file: var/run/sudo
security.selinux="system_u:object_r:pam_var_run_t:s0\000"

Comment 4 Dominick Grift 2008-04-25 08:39:16 EDT
i cannot reproduce it anymore. /var/run/sudo directories get added but not
deleted. however the type is proper.

ill remove directories in /var/run/sudo of user that do no longer exist manually