Bug 495122 - Various Winbind Errors after taking 5.3 Updates
Various Winbind Errors after taking 5.3 Updates
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: samba (Show other bugs)
5.3
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Guenther Deschner
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-09 16:12 EDT by Todd Thomas
Modified: 2010-05-17 10:41 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-17 10:41:37 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 Todd Thomas 2009-04-09 16:12:03 EDT
Description of problem:
After running samba 3.28 on RHEL 5.2 for over a year without error I finally downloaded the 5.3 updates. Samba was updated from 3.28 to 3.33. After the update AVC denials began populating /var/log/audit/audit.log:


Version-Release number of selected component (if applicable):
# smbd -V
Version 3.0.33-3.7.el5


How reproducible:
This is consistent with my test image (based on 5.2/samba 3.28)
which I have performed 3 times now.


Steps to Reproduce:
1. Install a copy of 5.2 (fully patched) with 
2. Samba 3.28 and the attached smb.conf file below.
3. run: yum -y update (patch only to the 5.3 packages)
3. reboot
  
Actual results: (this is just the highlight reel)
# cat /var/log/audit/audit.log | grep denied
Winbind cannot access secrets.tdb
type=AVC msg=audit(1239225692.311:1318): avc:  denied  { write } for  pid=7339 comm="winbindd" name="secrets.tdb" dev=dm-0 ino=950343 scontext=root:system_r:winbind_t:s0 tcontext=root:object_r:samba_etc_t:s0 tclass=file
This breaks samba if used in conjunction with ldap and all nt groups are stored in the ldap database.

SMBD cannont communicate with Winbind via the named pipe:
type=AVC msg=audit(1239302885.488:26017): avc:  denied  { connectto } for  pid=25591 comm="smbd" path="/var/run/winbindd/pipe" scontext=root:system_r:smbd_t:s0 tcontext=root:system_r:initrc_t:s0 tclass=unix_stream_socket
This one speaks for it's self.

Expected results:
Samba should have performed the same after the update, as it did before: without any AVC denials.


Additional info:
I'm still somewhat green with the rpm packaging concepts but it seems that restorcon should have been included in the install scripts within the samba rpms. If there's anything I can do to perform root-cause analysis please let me know.
Also, this is my first bug submission. If there are unfilled blanks above please route this, internally, the correct way. I'm not sure what your processes are. 

Thanks T
Comment 1 Simo Sorce 2009-04-09 16:57:06 EDT
Dan is this something we can/should address within the spec file, or is it something you need to change in the policy ?
(I think we already have a bug open for secrets.tdb, but can't find it right now)
Comment 2 Todd Thomas 2009-04-09 17:13:05 EDT

(In reply to comment #1)
> Dan is this something we can/should address within the spec file, or is it
> something you need to change in the policy ?
> (I think we already have a bug open for secrets.tdb, but can't find it right
> now)  

I ran a fairly exhaustive search myself for all keywords, secrets.tdb being one of them, and I didn't find anything that seemed to speak to this problem.

On the other points, yes, I can adjust the policy as a work-around but, again, if it can be fixed at the top level by including a restorecon statement in the scripting, resident within the distributed rpm, then it should diminish unnecessary hassles.

As I have never had a problem with this I've really never had to dig into it. My root-cause breakdown is weak, I know that. I'm leaving the most appropriate solution to those who can speak intelligently on the subject.
Comment 3 Daniel Walsh 2009-04-13 08:43:39 EDT
Something is causing secrets.tdb to be mislabeled.  If the post install of the samb script is recreating this file then it should run restorecon on it to make sure it is labeled correctly.

SMBD cannont communicate with Winbind via the named pipe:
type=AVC msg=audit(1239302885.488:26017): avc:  denied  { connectto } for 
pid=25591 comm="smbd" path="/var/run/winbindd/pipe"
scontext=root:system_r:smbd_t:s0 tcontext=root:system_r:initrc_t:s0
tclass=unix_stream_socket
This one speaks for it's self.

This indicates that smbd is trying to communicate with a process running as initrc_t, winbind?  Which indicates something was started incorrectly or some executable is not labeled correctly?  Or this is caused by the way the testing is run.  initrc_t means that something is running in the same context as the init script.
Comment 4 Todd Thomas 2009-04-13 17:03:27 EDT
Here are some resolution notes:

Find which processes are running as initrc_t:
# ps auxZ | grep initrc_t
system_u:system_r:initrc_t      root      2427  0.0  0.0  65292   276 ?        Ss   Apr08   0:00 rpc.rquotad
system_u:system_r:initrc_t      zimbra    3353  0.0  0.1  43160  9880 ?        S    Apr08   0:03 /usr/bin/perl /tmp/.swatch_script.3245
root:system_r:unconfined_t:SystemLow-SystemHigh root 4194 0.0  0.0 61172 736 pts/0 R+ 15:47   0:00 grep initrc_t
root:system_r:initrc_t          root      4965  0.0  0.0 109644  1888 ?        Ss   Apr08   0:00 winbindd
root:system_r:initrc_t          root      4966  0.0  0.0 109644  1880 ?        S    Apr08   0:00 winbindd
	*Both winbind processes are running under the user Type 'initrc_t'.
	**Also, rpc.rquotad is incorrect as well*****
	*This is only good while booting the system. 
	*This should be changed.
---
Locate the winbind startup script:
# locate winbindd
...
/etc/rc.d/init.d/winbind
...
---
# ls -lZ /etc/rc.d/init.d/winbind
-rwxr-xr-x  root root system_u:object_r:initrc_exec_t  /etc/rc.d/init.d/winbind
---
Restore the correct context back to the startup script and the binary:
# restorecon -R -v /etc/rc.d/init.d/winbind
# restorecon -v /usr/sbin/winbindd
---
Restart the winbind service:
# service winbind restart
---
Verify that the changes are correct. It would be difficult to wait for another AVC denial to NOT be dropped in audit.log so:
# ps auxZ | grep initrc_t
system_u:system_r:initrc_t      root      2427  0.0  0.0  65292   276 ?        Ss   Apr08   0:00 rpc.rquotad
system_u:system_r:initrc_t      zimbra    3353  0.0  0.1  43160  9880 ?        S    Apr08   0:03 /usr/bin/perl /tmp/.swatch_script.3245
system_u:system_r:initrc_t      zimbra    3379  0.0  0.1  45924  6320 ?        S    Apr08   0:08 /usr/bin/perl /opt/zimbra/libexec/zmlogger
root:system_r:unconfined_t:SystemLow-SystemHigh root 20590 0.0  0.0 61172 736 pts/0 R+ 16:21   0:00 grep initrc_t

Winbind is no longer running as user Type initrc_t.
---
Verify winbind is running in it's proper domain.
# ps auxZ | grep winbind
root:system_r:unconfined_t:SystemLow-SystemHigh root 4734 0.0  0.2 26496 16332 ? Ss Apr08   0:00 restorecond /var/run/winbindd/pipe
root:system_r:winbind_t         root     18316  0.0  0.0 109396  1908 ?        Ss   16:16   0:00 winbindd
root:system_r:winbind_t         root     18317  0.0  0.0 109648  2052 ?        S    16:16   0:00 winbindd
root:system_r:unconfined_t:SystemLow-SystemHigh root 20987 0.0  0.0 61172 740 pts/0 R+ 16:22   0:00 grep winbind

The proper user Type context has been restored back to the winbind service.
===
I'm not sure if these notes belong here so let me know how you would like these in the future if this not the right place for them.

In an effort to triangulate the problem I have burned down the test server to begin the process again. I have additional notes from that. Please let me know where to put them.

T
Comment 5 Daniel Walsh 2009-04-14 10:42:55 EDT
rpc.quotad should have a policy.

Fixed in selinux-policy-2.4.6-225.rhel5

I don't know why winbind was labeled incorrectly.
Comment 6 Daniel Walsh 2009-04-14 10:45:33 EDT
But after the install of samba, you need to make sure the secrets.tdb  file is correctly labeled.
Comment 7 Todd Thomas 2009-04-14 10:53:38 EDT
right you are:

# ls -lZ /etc/samba/secrets.tdb
-rw-------  root root root:object_r:samba_secrets_t    /etc/samba/secrets.tdb
===
This is as far as I've gotten on my own. If there is a clear path to verifying what the package IS that is boogering up the system after the 'blind' update, feel free to suggest.

BTW: at this point I still have yet to do the update to 5.3.
Comment 8 Dmitri Pal 2010-05-17 10:41:37 EDT
We believe it is addressed in the latest SELinux policy version. Please reopen if you can reproduce it.

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