selinux February 2009

selinux@lists.fedoraproject.org

43 participants
57 discussions

oddity with postfix delivering to homedir
by Manuel Wolfshant 18 Feb '09

18 Feb '09

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

4 12

bind-mounted homedirs
by Paul Howarth 18 Feb '09

18 Feb '09

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.

5 8

mount --bind and autorelabel versus restorecon
by Per Sjoholm 17 Feb '09

17 Feb '09

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

3 4

New fedora cgit packages could use some policy updates
by Todd Zullinger 17 Feb '09

17 Feb '09

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

4 8

Regexp syntax
by Per Sjoholm 17 Feb '09

17 Feb '09

Updating from CentOS 4.7 to 5.2 with targeting and enforcing. (Main reason for doing the update) Were can I find the syntax description for the regexp used in semange fcontext. And also some non trivial examples. I have read http://fedoraproject.org/wiki/SELinux/ManagingFileContext http://docs.fedoraproject.org/selinux-user-guide/f10/pdf/Security-Enhanced_… Thanks Per

3 3

denied avcs for kde again :(
by Antonio Olivares 17 Feb '09

17 Feb '09

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)

3 3

Re: myqsl dummy needs help
by Gene Heskett 16 Feb '09

16 Feb '09

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

2 2

Re: myqsl dummy needs help
by Gene Heskett 16 Feb '09

16 Feb '09

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

1 0

Auditd port 60 access in RHEL 5.2
by Dan Gruhn 16 Feb '09

16 Feb '09

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

3 4

Re: SELinux blocking Samba share mounting? [SOLVED]
by Paul Howarth 14 Feb '09

14 Feb '09

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.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux February 2009