Bug 443961 - pams (authlogin system module) objects in /var/run/sudo
pams (authlogin system module) objects in /var/run/sudo
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-24 08:36 EDT by Dominick Grift
Modified: 2008-04-25 08:39 EDT (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
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


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