oddity with postfix delivering to homedir
by Manuel Wolfshant
hello
I have migrated a working mailserver from Centos 4.7 to Centos 5.2.
The system uses postfix to receive messages from a mail relay and is
supposed to deliver them to folders named after the users, following
the /home/firstname.lastname@domain template. Authentication is done via
mysql against a db running on another system.
New accounts are created automatically when a mail has to be
delivered to an user which has never been seen before.
For the users which existed before migration, everything is fine.
However, for non-existing (i.e. to be created) users the homedir is
created with wrong contexts, which prohibit postfix to finalize the
delivery. Once a message is received for a new user, the following is
created:
[root@imap2 ~]# ll -Zl /home/gigi.test\(a)nobugconsulting.ro/ -R
/home/gigi.test(a)nobugconsulting.ro/:
total 8
drwx------ 2 root:object_r:home_root_t postfix postfix 4096 Feb
17 01:05 tmp
/home/gigi.test(a)nobugconsulting.ro/tmp:
total 4
-rw------- 1 root:object_r:home_root_t postfix postfix 0 Feb 17
01:05 1234825528.P26797.imap2
After that postfix tries to do stuff on the newly created file and
selinux kicks in and denies access.
Running restorecon at this point fixes things:
[root@imap2 ~]# restorecon -v -R
/home/gigi.test(a)nobugconsulting.ro
restorecon reset /home/gigi.test(a)nobugconsulting.ro context
root:object_r:home_root_t:s0->user_u:object_r:user_home_dir_t:s0
restorecon reset /home/gigi.test(a)nobugconsulting.ro/tmp context
root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0
restorecon reset
/home/gigi.test(a)nobugconsulting.ro/tmp/1234825528.P26797.imap2 context
root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0
I am running the following versions of packages:
[root@imap2 ~]# rpm -qa kernel\* \*selinux\* postfix\*
kernel-xen-2.6.18-92.1.22.el5
libselinux-utils-1.33.4-5.1.el5
selinux-policy-targeted-2.4.6-203.el5
libselinux-1.33.4-5.1.el5
libselinux-python-1.33.4-5.1.el5
selinux-policy-2.4.6-203.el5
postfix-2.3.3-2.1.centos.mysql_pgsql
Selinux related packages have been upgraded last night in the hope
to fix the problem, postfix is almost stock centosplus 5.2, recompiled
with support for mysql but without postgresql- support.
Obviously I no not want to follow the result of audit2allow,
home_root_t:dir should not be there in the first place:
[root@imap2 ~]# grep avc /var/log/audit/audit.log|audit2allow
#============= postfix_virtual_t ==============
allow postfix_virtual_t home_root_t:dir { write remove_name create
add_name };
allow postfix_virtual_t home_root_t:file { write create unlink link
getattr };
allow postfix_virtual_t postfix_private_t:dir search;
allow postfix_virtual_t postfix_private_t:sock_file write;
allow postfix_virtual_t usr_t:file { read getattr };
Correct access rights and contexts seem to be:
[root@imap2 ~]# ls -l /home/ -dZ
drwxr-xr-x+ postfix postfix system_u:object_r:home_root_t /home/
[root@imap2 ~]# ls -l /home/gigi.test\(a)nobugconsulting.ro/ -dZ
drwx------ postfix postfix user_u:object_r:user_home_dir_t
/home/gigi.test(a)nobugconsulting.ro/
The only user on the system (beside root) is postfix:
[root@imap2 ~]# getent passwd postfix
postfix:x:89:89::/var/spool/postfix:/sbin/nologin
raw content of audit log after a failed delivery for a never-seen
before user:
type=AVC msg=audit(1234873447.682:45616): avc: denied { write } for
pid=2958 comm="virtual"
path="/home/gigi.test(a)nobugconsulting.ro/tmp/1234873447.P2958.imap2"
dev=hda1 ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
tcontext=root:object_r:home_root_t:s0 tclass=file
type=SYSCALL msg=audit(1234873447.682:45616): arch=c000003e syscall=1
success=no exit=-13 a0=c a1=2b96176fe510 a2=1b5 a3=7228206f722e676e
items=0 ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89
egid=89 sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
exe="/usr/libexec/postfix/virtual"
subj=root:system_r:postfix_virtual_t:s0 key=(null)
type=AVC msg=audit(1234873447.710:45617): avc: denied { write } for
pid=2958 comm="virtual" name="1234873447.P2958.imap2" dev=hda1
ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
tcontext=root:object_r:home_root_t:s0 tclass=file
type=SYSCALL msg=audit(1234873447.710:45617): arch=c000003e syscall=77
success=no exit=-13 a0=c a1=0 a2=2 a3=0 items=0 ppid=26787 pid=2958
auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89 sgid=0 fsgid=89
tty=(none) ses=7290 comm="virtual" exe="/usr/libexec/postfix/virtual"
subj=root:system_r:postfix_virtual_t:s0 key=(null)
type=AVC msg=audit(1234873447.710:45618): avc: denied { remove_name }
for pid=2958 comm="virtual" name="1234873447.P2958.imap2"
dev=hda1ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
tcontext=root:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1234873447.710:45618): arch=c000003e syscall=87
success=no exit=-13 a0=2b96176fdb80 a1=64 a2=4 a3=2b95fb0340ec items=0
ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89
sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
exe="/usr/libexec/postfix/virtual"
subj=root:system_r:postfix_virtual_t:s0 key=(null)
My questions are
a) why does postfix create the initial home directories with a wrong
context ? Note this only happens for NEW users, messages for the users
which already existed [and have correct context] on the old system are
perfectly fine.
b) what can I do to fix ?
Tia
Manuel
15 years, 2 months
bind-mounted homedirs
by Paul Howarth
On a RHEL 5 server I have bind-mounted home directories, where the data
on the server actually lives in /srv/homes but this is bind-mounted to
/nis-home. The user home directories in LDAP refer to the /nis-home
locations.
When I updated to the 5.3 selinux policy, everything under /srv/homes
got relabelled based on the /srv/homes pathname rather than the
/nis-home pathname. What would be the best way of preventing this from
happening in the future?
Paul.
15 years, 2 months
mount --bind and autorelabel versus restorecon
by Per Sjoholm
There are more than one problem described here and the are connected.
One is the basic how to organize data regarding updates, backup and daily task.
One is SELinux protection.
One is this should NOT be a problem in the first place.
(IT was NOT until target/enforing policy)
I have systems and try to keep OS and data separated.
This makes backup and updating OS easier.
SELinux chamges things.
Normaly:
Partion 1,2 and 3 contain an OS and 4 is an extend partion with my data.
Then I can install a new OS and prepare it before changing over.
Keeping system running, rebooting into the new version.
Reverting to old OS version by a reboot if needed.
ONLY OS dependent data(config, deamon ..) is under "/" rest is elsewhere
and the physical file system for /dev/sda5 is mounted under /disk_dev/sda5.
with a mount --bind parts of /disk_dev/<part>/<subdir> get mounted i the proper place.
mount --bind /disk_dev/sda5/projects/A /prj/A
the NFS4 exports is an other example
Some clients use samba and some NFS parts of the data should be available via httpd, bittorrent.
Some of the files are large and can't be duplicated (symlinked)?
Most data belongs to A project and the project belongs to a group
SELinux
Using symlinks or an alias in httpd does not work as components in the path
is missing lables as they contain data that ftp,samba or httpd is not ment to read.
autorelabel only handles filesystem mounts NOT mount --bind
the result of
doing a touch /.autorelabel; reboot
doing a restorecon -R <path>
will differ as autorelable does only see the physical mount.
It's possible to construct file context and they will most likely NOT
work reliable for both autorelabel and restorecon
Thanks
Per
15 years, 2 months
New fedora cgit packages could use some policy updates
by Todd Zullinger
Greetings,
I added a cgit package to Fedora yesterday. It's only in rawhide at
the moment. cgit is a cgi used to provide a web interface for viewing
git repositories (similar to gitweb¹).
Is the preferred method to add policy to the selinux-policy package or
are package policy modules the way to go? I thought the former was
preferred, but I can't find anything on the wiki other than
http://fedoraproject.org/wiki/PackagingDrafts/SELinux, which seems
like it might have been a stalled attempt.
The cgit requirements are fairly minimal, AFAICT. It needs:
* write access to its cache dir, /var/cache/cgit
* read access to git repositories, which default to /var/lib/git,
but are likely to be changed by admins (/srv/git is one popular
choice). For the moment, I created a README.SELinux file in the
package that details how to set generic contexts to allow the
package to work².
That README suggests httpd_sys_content_rw_t for the cache and
httpd_sys_content_t (or public_content_t) for the git repos. It's
quite likely that we'd want a more specific type for the cache dir
especially.
Additionally, the cgi itself needs to be httpd_sys_script_exec_t,
which happens automagically by virtue of installing it in
/var/www/cgi-bin/cgit.
Any help or suggestions would be most welcome. I'd like to get these
things worked out before I build the package for F-9, F-10, and EL-5.
If crafting a policy requires moving anything around, I'd like to do
that before many users install the package and modify their configs.
¹ gitweb has some SELinux issues on F-10 itself, I filed this as
https://bugzilla.redhat.com/479613 the other day.
² http://cvs.fedoraproject.org/viewvc/rpms/cgit/devel/README.SELinux?view=co
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Well at first I was skeptical but then I thought I could be like
Hillary Clinton, just without the penis.
-- Lois Griffin, The Family Guy
15 years, 2 months
denied avcs for kde again :(
by Antonio Olivares
Am I the only that one that sees the following :
I think I am going crazy with these repeating avc's :(
Summary:
SELinux prevented kde4-config from writing .kde.
Detailed Description:
SELinux prevented kde4-config from writing .kde. If .kde is a core file, you may
want to allow this. If .kde is not a core file, this could signal a intrusion
attempt.
Allowing Access:
Changing the "allow_daemons_dump_core" boolean to true will allow this access:
"setsebool -P allow_daemons_dump_core=1."
Fix Command:
setsebool -P allow_daemons_dump_core=1
Additional Information:
Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context system_u:object_r:root_t:s0
Target Objects .kde [ dir ]
Source kde4-config
Source Path /usr/bin/kde4-config
Port <Unknown>
Host riohigh
Source RPM Packages kdelibs-4.2.0-10.fc11
Target RPM Packages
Policy RPM selinux-policy-3.6.5-3.fc11
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name allow_daemons_dump_core
Host Name riohigh
Platform Linux riohigh 2.6.29-0.119.rc5.fc11.i586 #1 SMP
Sat Feb 14 18:38:24 EST 2009 i686 athlon
Alert Count 3
First Seen Thu 12 Feb 2009 08:38:18 AM CST
Last Seen Mon 16 Feb 2009 06:56:52 AM CST
Local ID 8e781235-d7ca-4c98-b8c9-ed9dac40a2ff
Line Numbers
Raw Audit Messages
node=riohigh type=AVC msg=audit(1234789012.965:7): avc: denied { create } for pid=2245 comm="kde4-config" name=".kde" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:root_t:s0 tclass=dir
node=riohigh type=SYSCALL msg=audit(1234789012.965:7): arch=40000003 syscall=39 success=no exit=-13 a0=82fc358 a1=1c0 a2=2f0438c a3=1 items=0 ppid=2244 pid=2245 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kde4-config" exe="/usr/bin/kde4-config" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
15 years, 2 months
Re: myqsl dummy needs help
by Gene Heskett
On Monday 16 February 2009, Craig White wrote:
>On Mon, 2009-02-16 at 17:52 -0500, Gene Heskett wrote:
>> On Monday 16 February 2009, Craig White wrote:
>> >On Mon, 2009-02-16 at 15:51 -0500, Gene Heskett wrote:
>> >> On Monday 16 February 2009, Anne Wilson wrote:
>> >> >On Monday 16 February 2009 20:27:04 Gene Heskett wrote:
>> >> >> No package webmin available.
>> >> >> Nothing to do
>> >> >
>> >> >I don't think I've ever had webmin from a distro package, but it
>> >> > installs so easily from the website.
>> >> >
>> >> >Anne
>> >>
>> >> I found it, installed it, let it do its updates, but a scan for servers
>> >> doesn't find mysql cuz it is not running and now won't run.
>> >>
>> >> I had NDI this was going to such a PIMA, but a friend has mythtv
>> >> running at his place and it does everything but fix breakfast.
>> >>
>> >> If anyone has any idea how to reset this SOB to absolutely square one,
>> >> never having been run, please advise. Deleting /var/lib/mysql didn't
>> >> do it.
>> >
>> >----
>> >you don't delete /var/lib/mysql
>> >you delete /var/lib/mysql/*
>> >
>> >mkdir /var/lib/mysql
>> >chown mysql:mysql /var/lib/mysql
>> >service mysqld start
>>
>> I got to here ^^^ and selinux stuck up its hand & waved at me.
>> SELinux is preventing mysqld (mysqld_t) "create" to mysql.sock
>> (var_lib_t).
>>
>> And recommended I run restorecon -v 'mysql.sock', but:
>> [root@coyote rpms]# restorecon -v 'mysql.sock'
>> restorecon: stat error on mysql.sock: No such file or directory
>>
>> So I go back to the top of the list above and repeat, apparently forever
>> cuz I get the same thing when I restart mysqld.
>>
>> Now, since mysql.sock doesn't exist, because it can't create it, therefore
>> restorecon can't do anything about it, WTH do I do next?
>>
>> So I located the old one in the database, touched a new one, then
>> 'chown mysql:mysql mysql.sock;restorecon -v mysql.sock' No errors
>> reported. But, a 'service mysqld start' eventually fails. And now the
>> selinux count is plus 2 cuz I tried it twice.
>>
>> So how do we fix YAMYSQLFSCKUP?
>
>----
>ignoring that the person whining is the one who deleted the directory in
>the first place, it should have been obvious to you that you needed to
>also restore the security contexts on /var/lib/mysql when you recreated
>it.
>
>Are you having a good time blaming everything else for your troubles?
>
>There are millions of people running mysql without your issues.
>
>Craig
With all due respect Craig, it must have done it once, over a year ago, but I
haven't been using it for anything. I had yum rpm -e the whole thing which
took a few other things along with it, then reinstalled the whole maryann.
No change. If, when it was installed originally, it spit out any such errors,
I don't after a year, recall them, and selinux has been updated a dozen times
since the install and my re-enabling selinux. So lets be realistic and see
just what the hell we can do about selinux killing mysql instead of your
usual shoot the messenger attitude.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"Open the pod bay doors, HAL."
-- Dave Bowman, 2001
15 years, 2 months
Re: myqsl dummy needs help
by Gene Heskett
On Monday 16 February 2009, Mike Wright wrote:
>locate mysql | grep '/bin/' | grep install
/usr/bin/mysql_install_db
/usr/bin/mysql_secure_installation
The secure installer asks me for my root pw then tells me to just press enter
Enter current password for root (enter for none):
ERROR 2002 (HY000): Can't connect to local MySQL server through
socket '/var/lib/mysql/mysql.sock' (2)
Enter current password for root (enter for none):
So I ctl-c it and run the install_db, which gets me back to the selinux & its
used bull food leavings.
Do I need to touch /.autorelabel and reboot? With 2TB of drives I can't begin
to describe how painful that 4 hours would be.
Or go file a bug against selinux and mysql?
Frustration reigns supreme here. If I have to reboot, it might just be to
Kubuntu-8.10 or a beta of 9.4.
Added that (selinux) list to To: Daniel, your turn, it's 18:05 here, and I've
been screwing with this since about 18:00 yesterday. That is long enough
IMO. This thread has a now VERY lengthy thread on the fedora list.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
There appears to be irrefutable evidence that the mere fact of overcrowding
induces violence.
-- Harvey Wheeler
15 years, 2 months
Auditd port 60 access in RHEL 5.2
by Dan Gruhn
Greetings,
I am posting here a the suggestion of Steve Grubb from the linux-audit
list. My apology for being on a Fedora list with a RHEL question but
hopefully the reasoning will be apparent.
I have a 64 bit RHEL 5.2 system that I have built and installed all of
the necessary packages for the latest audit (1.7.11-1), prelude and
prewikka. (I'd rather use Fedora, but the security people are more
comfortable with RHEL). This all seems to be working fine on the
central cluster server and now I'm trying to set up clients in the
cluster nodes to report their audit information to the server. I've
found the RHEL 5.3 release notes where it says:
...
Because the auditd daemon is protected by SELinux, semanage (the
SELinux policy management tool) must also have the same port listed
in its database. If the server and client machines had all been
configured to use port 60 for example, then running this command
would accomplish this:
semanage port -a -t audit_port_t -p tcp 60
...
I'm trying to run the semanage command to let selinux know that port 60
is acceptable for audit to use but I get the following error message
when I run the command:
# semanage port -a -t audit_port_t -p tcp 60
libsepol.context_from_record: type audit_port_t is not defined
libsepol.context_from_record: could not create context structure
libsepol.port_from_record: could not create port structure for range
60:60 (tcp)
libsepol.sepol_port_modify: could not load port range 60 - 60 (tcp)
libsemanage.dbase_policydb_modify: could not modify record value
libsemanage.semanage_base_merge_components: could not merge local
modifications into policy
/usr/sbin/semanage: Could not add port tcp/60
I'm not much of a wiz at selinux, but I can tell that the audit_port_t
type doesn't exist. I'm stuck here because:
1) I don't know how to create new types in selinux
2) Even if I figured that out, I don't know how auditd would know to use
that.
I've looked at the auditd executable, it has types like this:
-rwxr-x--- root root system_u:object_r:auditd_exec_t /sbin/auditd
In talking with Steve I was hoping to somehow get the SELinux policy
piece for auditd from 5.3 the add into the latest audit that I have
compiled. He suggested that:
You need to be using the SE Linux policy from the 5.3 update. Before 5.3, auditd never had a listening port and therefore selinux policy prior to it wouldn't have setup that type. I also think SE Linux policy may default to port 60 even though that port may not be guaranteed in the future.
I told Steve that the system is a stand-alone in a secure environment
and it is currently locked into 5.2 as we're working to get it approved
by various powers. When I asked if there any way to get the SE Linux
policy from the 5.3 update as a separate piece he replied:
I was hoping Dan Walsh would answer...its possible, but I don't know if the selinux people pull it with a bunch of other changes into the reference policy or not. You might be able to just get the 5.3 policy and look for the audit files and transplant them into 5.2 policy and diff against original 52 policy to make a patch. You might need to ask on the Fedora-selinux mail list or the NSA selinux policy mail list if no one answers soon.
Could someone give me some pointers and/or point me to something I could
read to get me going? I have the 5.3 audit RPMs, but can't seem to find
the right pieces.
Thanks,
Dan
15 years, 2 months
Re: SELinux blocking Samba share mounting? [SOLVED]
by Paul Howarth
On Fri, 13 Feb 2009 18:04:29 -0500
Steven Stromer <filter(a)stevenstromer.com> wrote:
>
> On Feb 13, 2009, at 5:30 PM, Paul Howarth wrote:
>
> > 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.
>
>
> 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.
15 years, 2 months