On Fri, 13 Feb 2009 18:04:29 -0500
Steven Stromer <filter@xxxxxxxxxxxxxxxxx> wrote:
>
> On Feb 13, 2009, at 5:30 PM, Paul Howarth wrote:
>
> > 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.
>
>
> Paul, You are the man.
>
> /home was labelled default_t. Changing its label (non-recursively)
> to user_home_dir_t set everything right! I won't even ask how or why
> it 'defaulted' to default_t in the first place. If you've got the
> chance to explain, I'm always ready for a lesson, but, for the
> moment, I am more than pleased to be up and running. Thank you for
> the expert assistance!
I'm at a loss to explain how /home became default_t given that you very
recently did a "restorecon -RF /home" (cited above). Good to hear
everything's working now though.
Paul.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
