On Fri, 13 Feb 2009 16:45:41 -0500 Steven Stromer filter@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.
selinux@lists.fedoraproject.org
-
Paul Howarth