Description of problem: SELinux is preventing /usr/sbin/crond (crond_t) "audit_control" to (crond_t). avc: denied { audit_control } for comm="crond" egid=0 euid=0 exe="/usr/sbin/crond" exit=-1 fsgid=0 fsuid=0 gid=0 items=0 pid=3131 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 suid=0 tclass=capability tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tty=(none) uid=0 Version-Release number of selected component (if applicable): vixie-cron-4.1-82.fc7 [application] How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
selinux-policy-2.6.4-17.fc7 from updates-testing 20070619
Fixed in selinux-policy-2.6.4-20.fc7
selinux-policy-2.6.4-20.fc7 SELinux is preventing /usr/sbin/crond (crond_t) "transition" to /bin/bash (unconfined_t). vixie-cron-4.1-82.fc7 [application]bash-3.2-9.fc7 [target] avc: denied { transition } for comm="crond" dev=dm-0 egid=0 euid=0 exe="/usr/sbin/crond" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="bash" path="/bin/bash" pid=4029 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 suid=0 tclass=process tcontext=user_u:system_r:unconfined_t:s0 tty=(none) uid=0 SELinux is preventing /usr/sbin/anacron (crond_t) "write" to cron.daily (var_spool_t) avc: denied { write } for comm="anacron" dev=dm-0 egid=0 euid=0 exe="/usr/sbin/anacron" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="cron.daily" pid=2578 scontext=system_u:system_r:crond_t:s0 sgid=0 subj=system_u:system_r:crond_t:s0 suid=0 tclass=file tcontext=system_u:object_r:var_spool_t:s0 tty=(none) uid=0
restorecon -R -v /var/spool Are you sure you are still seeing the transition problem after upgrading the policy?
Created attachment 157556 [details] auditlogafterboot-21 Looks good for cron Attachment shows fairly clean boot up and running for a couple of hours. I still have the cups issue for shared windows printing. See next attachment.
Created attachment 157557 [details] copyalerts for bug 199631 for bug 199631 followup Copy alerts from cups printing Linux to Win Xp. cups uses smb, /tmp/spool, note first alert - seems to be a general note about higher level dirs not label correctly? relabel dos not affect it. than you, Darwin
Why would cups use /tmp/spool instead of /var/run? Also why is smbspool doing a getattr on all files in /tmp?
I can't answer that. From my view it is a point and click operation. This has been like this since mid-fc6 when the new print system was installed. Aside from clearing up the avc , I then have the real problem to address, why won't the Windows auth my request? It hasn't changed since FC3 and samba and cups worked fine through the first part if FC6. In fact, running ubuntu 5.10 I could set up the samba sever, samba client and cups on two Linux machines, pointing at the win Xp and everything would be working in a half an hour - both ways to every machine. Then it all stooped and the only thing that works now is the smb-client to a win share. And that's all I know. Darwin
Sorry Darwin, I meant the question to Simo and Tim who I added as CC to the list. You can get this to work on your machine with SELinux by executing # yum install checkpolicy # grep cups /var/log/audit/audit.log | audit2why -M mycups # semodule -i mycups.pp
I don't know why cups want to use /tmp/spool, for smbspool, it may be searching for a kerberos cache file in /tmp (at least I see code that opens TICKET_CC_DIR and do a readdir). It may or may not be that.
The default /etc/samba/smb.conf file incorrectly contains: path = /tmp/spool/samba in the [printing] section. It ought to be changed to /var/spool/samba.
That is just an example, but I'll change it, thanks for spotting it.
Actually I just checked and the shipped packages have the right path. Do you have an older smb.conf? (FC6?)
This looks like it has morphed in to a samba bug
Darwin, do you still have the auth problem? Or was it solved upgrading the selinux policies?
The information we've requested above is required in order to review this problem report further and diagnose/fix the issue if it is still present. Since there have not been any updates to the report since thirty (30) days or more since we requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. Setting status to "CLOSED INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. Thank you in advance. Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.