On Fri, 13 Feb 2009 16:45:41 -0500
Steven Stromer <filter@xxxxxxxxxxxxxxxxx> 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.
>
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
