Bug 443961 - pams (authlogin system module) objects in /var/run/sudo
Summary: pams (authlogin system module) objects in /var/run/sudo
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy   
(Show other bugs)
Version: rawhide
Hardware: All Linux
low
low
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-24 12:36 UTC by Dominick Grift
Modified: 2008-04-25 12:39 UTC (History)
1 user (show)

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: ---


Attachments (Terms of Use)

Description Dominick Grift 2008-04-24 12:36:43 UTC
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 18:07:23 UTC
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 10:24:56 UTC
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 11:10:38 UTC
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 12:39:16 UTC
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




Note You need to log in before you can comment on or make changes to this bug.