SELinux blocking Samba share mounting?

[Paul Howarth]

On Fri, 13 Feb 2009 16:45:41 -0500
Steven Stromer <filter at stevenstromer.com> wrote:

> 
> >> Paul,
> >> Thanks for the time! I understand what you are saying. I have set:
> >> chcon -R -h -t home_root_t /home
> >> so that the entire path's heirarchy will be consistent,
> >
> > No no, this is wrong. home_root_t is for directories that
> > *contain* home directories, not the home directories and their
> > contents themselves.
> >
> > I'd do a "restorecon -RF /home" to fix that, then put back the  
> > contexts on your share areas as you wanted them (e.g.
> > samba_share_t or public_content_rw_t etc.).
> 
> Executed:
> restorecon -RF /home
> chcon -R -h -t samba_share_t /home/server1/PHFiles/
> 
> > Better still, I'd move your shares from under /home to under /srv
> > if that's a possibility.
> 
> Due to partitioning and backup schema, this would not be an ideal  
> solution, if avoidable.
> 
> > > and then:
> > setsebool -P use_samba_home_dirs 1
> 
> Done.

Whoops, I got the wrong boolean. The one you want is
samba_enable_home_dirs, not use_samba_home_dirs. The former allows
samba to serve out home dirs, the latter allows use of home dirs
mounted from a samba server.

> >> Tried connecting, but still unsuccessful, so, output of
> >> audit2allow < /var/log/audit/audit.log is:
> >> #============= smbd_t ==============
> >> allow smbd_t home_root_t:dir { search getattr };
> >> allow smbd_t httpd_sys_content_t:dir search;
> >> Trying to mount /home/server1/PHFiles generates in /var/log/audit/ 
> >> audit.log:
> >> type=AVC msg=audit(1234540788.851:16207): avc:  denied
> >> { search } for  pid=26783 comm="smbd" name="/" dev=dm-2 ino=2  
> >> scontext=root:system_r:smbd_t:s0  
> >> tcontext=system_u:object_r:home_root_t:s0 tclass=dir
> >> type=SYSCALL msg=audit(1234540788.851:16207): arch=c000003e  
> >> syscall=4 success=no exit=-13 a0=2b119e168ff0 a1=7fff19c3c6a0  
> >> a2=7fff19c3c6a0 a3=3 items=0 ppid=17598 pid=26783 auid=0 uid=500  
> >> gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500  
> >> tty=(none) ses=122 comm="smbd" exe="/usr/sbin/smbd"  
> >> subj=root:system_r:smbd_t:s0 key=(null)
> >
> > Contexts need repairing before looking at these again.
> 
> New output of audit2allow < /var/log/audit/audit.log is:
> 
> #============= smbd_t ==============
> allow smbd_t default_t:dir search;
> allow smbd_t home_root_t:dir { search getattr };
> allow smbd_t httpd_sys_content_t:dir search;
> 
> 
> New /var/log/audit/audit.log output is:
> 
> type=AVC msg=audit(1234559350.144:16265): avc:  denied  { search }  
> for  pid=30226 comm="smbd" name="/" dev=dm-2 ino=2  
> scontext=root:system_r:smbd_t:s0  
> tcontext=system_u:object_r:default_t:s0 tclass=dir
> type=SYSCALL msg=audit(1234559350.144:16265): arch=c000003e
> syscall=4 success=no exit=-13 a0=2b119e17f7d0 a1=7fff19c3c6a0
> a2=7fff19c3c6a0 a3=3 items=0 ppid=17598 pid=30226 auid=0 uid=500
> gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none)
> ses=122 comm="smbd" exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0
> key=(null) type=AVC msg=audit(1234559350.276:16266): avc:  denied
> { search } for  pid=30229 comm="smbd" name="/" dev=dm-2 ino=2  
> scontext=root:system_r:smbd_t:s0  
> tcontext=system_u:object_r:default_t:s0 tclass=dir
> type=SYSCALL msg=audit(1234559350.276:16266): arch=c000003e
> syscall=4 success=no exit=-13 a0=2b119e17f7d0 a1=7fff19c3c6a0
> a2=7fff19c3c6a0 a3=3 items=0 ppid=17598 pid=30229 auid=0 uid=500
> gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none)
> ses=122 comm="smbd" exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0
> key=(null)

The root directory of one of the filesystems mounted on your system is
labelled default_t it would seem. See if you can find it and do a
non-recursive restorecon on it.

Also try to find the audit log entry associated with the
httpd_sys_content_t AVC.

> >> Trying to mount /var/www/html generates
> >> in /var/log/audit/audit.log: type=AVC
> >> msg=audit(1234540890.725:16214): avc:  denied  { search } for
> >> pid=26785 comm="smbd" name="www" dev=dm-3 ino=6815745
> >> scontext=root:system_r:smbd_t:s0
> >> tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir
> >> type=SYSCALL msg=audit(1234540890.725:16214): arch=c000003e
> >> syscall=4 success=no exit=-13 a0=2b119e168ff0 a1=7fff19c3c6a0
> >> a2=7fff19c3c6a0 a3=3 items=0 ppid=17598 pid=26785 auid=0 uid=500
> >> gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500
> >> tty=(none) ses=122 comm="smbd" exe="/usr/sbin/smbd"
> >> subj=root:system_r:smbd_t:s0 key=(null)
> >
> > /var/www is supposed to be readable under httpd only, not samba,
> > so it's normal for these not to work. For both servers to be able
> > to access the files (and samba to write them), you'll need /var/www
> > and everything underneath it to be public_content_rw_t and to set
> > the boolean allow_smbd_anon_write.
> 
> 
> Success here! Thought I'd tried this previously without success  
> (shrug...)  However, this time the following worked a charm! Thank
> you for your patience!
> 
> chcon -R -h -t public_content_rw_t /var/www
> setsebool -P allow_smbd_anon_write=1
> 
> Maybe I had accidentally executed the following without realizing:
> chcon -R -h -t public_content_rw_t /var/www/html
> 
> (By way of explanation, this host acts as a web site development  
> environment, and having samba access to the web files makes some  
> tasks, such as searching and replacing text in multiple files,
> faster and easier for some developers than via sftp or the command
> line.)
> 
> 
> > If you need CGI scripts rather than just static content and
> > built-in scripting (e.g. PHP) then you'll need a local policy
> > module to allow samba access using the existing httpd_* types
> > instead.
> 
> Thanks. I'm aware to set .cgi, .pl, .sh and similar to  
> httpd_sys_script_exec_t.

Once you've done that you'll no longer be able to access those files
using samba of course...

Paul.

>