Bug 175922 - winbindd can't write /etc/samba/secrets.tdb
Summary: winbindd can't write /etc/samba/secrets.tdb
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: samba
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Simo Sorce
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-12-16 11:32 UTC by Leonard den Ottolander
Modified: 2009-05-18 20:11 UTC (History)
7 users (show)

Clone Of:
Last Closed: 2009-05-18 20:11:25 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0969 normal SHIPPED_LIVE samba bug fix and enhancement update 2009-05-18 13:40:41 UTC

Description Leonard den Ottolander 2005-12-16 11:32:26 UTC

Dec 16 12:23:03 george-harrison kernel: audit(1134732183.671:24): avc:  denied 
{ write } for  pid=31578 comm="winbindd" name="secrets.tdb" dev=hda6 ino=94649
scontext=root:system_r:winbind_t tcontext=root:object_r:samba_etc_t tclass=file
Dec 16 12:23:03 george-harrison winbindd[31578]: [2005/12/16 12:23:03, 0]
Dec 16 12:23:03 george-harrison winbindd[31578]:   Failed to open
Dec 16 12:23:03 george-harrison winbindd[31578]: [2005/12/16 12:23:03, 0]
Dec 16 12:23:03 george-harrison winbindd[31578]:   Could not initialize domain
trust account secrets. Giving up 
Dec 16 12:23:03 george-harrison winbind: winbindd startup succeeded <sic>

# service winbind status
winbindd dead but subsys locked

Comment 1 Daniel Walsh 2005-12-16 14:05:51 UTC
Wrong context on secrets.tdb.


restorecon /etc/samba/secrets.tdb

It should be

ls -lZ /etc/samba/secrets.tdb
-rw-------  root     root     system_u:object_r:samba_secrets_t

Comment 2 Leonard den Ottolander 2005-12-31 13:19:13 UTC
# ls -lZ /etc/samba/secrets.tdb
-rw-------  root     root     root:object_r:samba_etc_t      /etc/samba/secrets.tdb

restorecon indeed fixes the issue.

How did that file get the wrong context? I haven't touched it.

Comment 3 Daniel Walsh 2006-01-02 13:36:16 UTC
I don't know, this would happen if the file was created by a program that did
not have selinux context on it, or if you booted the system with selinux
disabled and created the file.  

Comment 4 Russell Coker 2006-04-13 09:57:43 UTC
If you run "smbpasswd -a user" when the /etc/samba/secrets.tdb file does not 
exist then it will create the file.  The smbpasswd program also creates 
the /etc/samba/smbpasswd file so we can't use automatic transition rules to 
give the correct types.  Incidentally the secrets.tdb file is never recreated, 
so once it's been correctly labeled this problem will never reappear.

The problem is that when a program creates two files with different security 
requirements (in this case the smbpasswd file is read-only for winbind whule 
secrets.tdb is writable) in the same directory the only way of restricting 
permissions as much as we desire is to have the program in question be SE 
Linux aware.

I've just filed a new bugzilla #188896 against samba in regard to this issue.  
I filed it against the devel version because changes to samba in this regard 
are not going to be back-ported to RHEL.

Realistically we have two options for RHEL support.  One is that people just 
relabel the file as a work-around (you only need to do it once in the life of 
the machine).  The other option is to grant the same access to samba_etc_t and 
samba_secrets_t to make the problem go away (with a slight reduction in 

Comment 5 Russell Coker 2006-04-16 10:43:33 UTC
Steve Grubb has suggested a work-around for this.  Have the samba-common 
package %post script touch the file /etc/samba/secrets.tdb and then run 
restorecon on it.  This will have it start with the correct context.

I can't think of any better solution than this which would be a candidate for 
a RHEL4 update.

Comment 6 Juha Tuomala 2008-10-27 14:37:26 UTC
audit(1225112672.717:27): avc:  denied  { read write } for  pid=2102 comm="nmbd" name="secrets.tdb" dev=cciss/c0d0p3 ino=197154 scontext=root:system_r:nmbd_t:s0 tcontext=root:object_r:samba_secrets_t:s0 tclass=file

Same here, on centos5.

Prefix bug #188896 right so bugzilla creates working links.

comment #4:
> One is that people just relabel the file as a work-around 
> (you only need to do it once in the life of the machine).

My wild guess is, that shipping a product that does not 
work out-of-the-box does not increase sales, regardless
how logical it might sound.

I know a lot of people who, as a first thing, switch off 
the selinux from fresh machine. Having this kind of 
bugs open for three years is the reason for it.

Comment 7 Juha Tuomala 2008-10-27 14:42:33 UTC
This has been fixed in fedora rawhide, should be pushed to el5 even the file locations have changed.

Comment 16 errata-xmlrpc 2009-05-18 20:11:25 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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