Bug 443961
| Summary: | pams (authlogin system module) objects in /var/run/sudo | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dominick Grift <domg444> |
| Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | 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 12:39:44 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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 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" 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 |
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.