On Fri, 13 Feb 2009 16:45:41 -0500
Steven Stromer <filter(a)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.