Bug 150983

Adding these directives to my domains/misc/local.te file, then
reloading the generated policy, allows logrotate to run.  I'm
pretty sure it's not quite right, but may work for you anyway.

allow logrotate_t tmpfs_t:filesystem { associate };
allow var_log_t tmpfs_t:filesystem { associate };
allow var_t tmpfs_t:filesystem { associate };

allow logfile tmpfs_t:filesystem associate; would allow all types marked with
the "logfile" attribute to be created in a tmpfs filesystem.
allow file_type tmpfs_t:filesystem associate; would allow all file types to be
created in a tmpfs filesystem.

What is less clear is why logrotate chooses to create in /tmp vs. creating
the temporary file in /var/log itself, as the latter approach would avoid this
problem as well as avoiding the typical risks associated with using files in
/tmp (due to the fact that any process can create files, including malicious
symlinks, there).

I will add this to policy, but it looks like the requirement for this has been
removed from Rawhide.  logrotate-3.7.1-9 is no longer using a script in /tmp.

Peter are we looking at this for an update release?

(In reply to comment #3)
> I will add this to policy, but it looks like the requirement for this has been
> removed from Rawhide.  logrotate-3.7.1-9 is no longer using a script in /tmp.
> 
> Peter are we looking at this for an update release?

Do u mean logrotate update for RHEL? I think is good to add this policy into RHEL.
Logrotate will stay using /tmp in RHEL. 

An update to my original report.  I've been using RHEL4 with targeted-policy for
a month now, and applied all updates as they were released.  In my original
report I stated that I hadn't tried to reproduce the problem.

Every week I get an e-mail reporting logrotation errors, and every week I find
the messages below (except for the date, of course) at the bottom of
/var/log/messages.1.

Apr 17 03:04:04 nemesis kernel: audit(1113721444.679:0): avc:  denied  { setgid
} for  pid=13380 exe=/usr/bin/python capability=6
scontext=system_u:system_r:mailman_mail_t
tcontext=system_u:system_r:mailman_mail_t tclass=capability
Apr 17 03:04:04 nemesis kernel: audit(1113721444.836:0): avc:  denied  {
associate } for  pid=13378 exe=/usr/sbin/logrotate name=logrotate.HH3tfF
scontext=system_u:object_r:mysqld_log_t tcontext=system_u:object_r:tmpfs_t
tclass=filesystem

I do not use either mailman or mysql, so this behavior comes from the default
configurations as installed by the relevant RPMs.

Can you change your fstab entry to 

none  /tmp    tmpfs   defaults,noatime,fscontext=system_u:object_r:tmp_t 0 0

That actually makes the situation worse.  In my original report I note that a
service I don't actually use can't have it's (empty) log rotated.  Your proposed
change prohibits me from making use of software that I do use.

After remounting, I tried to use the Pine mail client and was told that the mail
folder was in use and would be accessed in read-only mode.  Hmmmm...  Looking at
the system log I see this:

May 12 19:22:36 nemesis kernel: audit(1115940156.284:0): avc:  denied  {
associate } for  pid=26203 exe=/usr/bin/pine name=.301.47636
scontext=root:object_r:tmp_t tcontext=system_u:object_r:tmp_t tclass=filesystem
May 12 19:22:36 nemesis pine: Mailbox lock file /tmp/.301.47636 open failure:
Permission denied

Pine is just the first program I tried.  Gaining the ability to rotate mysql.log
files (assuming that this is now possible) at the expense of some/all programs
that create temporary files on /tmp seems like a very poor trade-off.

Which policy are you now running.  I have this running in my environment without
any problems.

Dan

I'm using the same policy as I selected on the initial installation: 

  SELINUX=enforcing
  SELINUXTYPE=targeted

I think SELinux is a serious pain in the ass, and I'm not sure I see the benefit
over traditional Unix permission-based security.  Nevertheless, having installed
it, I'm determine to make it work.  Fortunately my only ongoing problem is with
mysql, a service I don't use.

I don't know if this is helpful, but this is what is logged at boot time:

kernel: SELinux:  Initializing.
kernel: SELinux:  Starting in permissive mode
kernel: SELinux:  Registering netfilter hooks
kernel: SELinux:  Completing initialization.
kernel: SELinux:  Setting up existing superblocks.
kernel: SELinux: initialized (dev hda1, type ext3), uses xattr
kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
kernel: SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
kernel: SELinux: initialized (dev mqueue, type mqueue), not configured for labeling
kernel: SELinux: initialized (dev hugetlbfs, type hugetlbfs), not configured for
labeling
kernel: SELinux: initialized (dev devpts, type devpts), uses transition SIDs
kernel: SELinux: initialized (dev eventpollfs, type eventpollfs), uses
genfs_contexts
kernel: SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
kernel: SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
kernel: SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
kernel: SELinux: initialized (dev proc, type proc), uses genfs_contexts
kernel: SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
kernel: SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
kernel: SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
kernel: SELinux: initialized (dev hda3, type ext3), uses xattr
kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
kernel: SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses
genfs_contexts

Please update to the policy and policycoreutils in 

ftp://people.redhat.com/dwalsh/SELinux/RHEL4/u1/

Most of your problems will be fixed here.  

Dan

I've run into the same problem, and install updated policy and policycoreutils
packages:

selinux-policy-targeted-1.17.30-2.88
policycoreutils-1.18.1-4.3

I also placed this in /etc/rc.sysinit (as suggested in one of the comments in
bug report for /tmp on tmpfs):

[ -n "$SELINUX" ] && restorecon /tmp

However I'm still getting the same error when running logrotate:

kernel: audit(1117469227.472:0): avc:  denied  { associate } for  pid=2799
exe=/usr/sbin/logrotate name=logrotate.GYV05O scontext=system_u:object_r:var_t
tcontext=system_u:object_r:tmpfs_t tclass=filesystem

It seems that it is generated during the rotation of /var/account/pacct file.

# ls -Za /tmp
drwxrwxrwt  root     root     system_u:object_r:tmp_t          .
drwxr-xr-x  root     root     system_u:object_r:root_t         ..
drwxrwxrwt  root     root     user_u:object_r:tmp_t            .ICE-unix

# ls -Za /var/account /var/account
drwxr-xr-x  root     root     system_u:object_r:var_t          .
drwxr-xr-x  root     root     system_u:object_r:var_t          ..
-rw-------  root     root     system_u:object_r:var_t          pacct
-rw-------  root     root     system_u:object_r:var_t          pacct.1
-rw-------  root     root     root:object_r:var_t              pacct.2.gz
-rw-------  root     root     root:object_r:var_t              pacct.3.gz
-rw-------  root     root     root:object_r:var_t              pacct.4.gz
[ ... and so on ... ]

The pacct file gets rotated, however postrotate script fails.  This is what gets
printed when running logrotate -vf /etc/logrotate.conf:

running postrotate script
error creating /tmp/logrotate.y93Js1: Permission denied
error: error running postrotate script

I'm using patched /etc/logrotate.d/psacct, as described in one of logrotate's
bug reports (if I remember correctly, the change is commited into CVS, so I
guess it should also be part of U1 or U2):

/var/account/pacct {
    compress
    delaycompress
    notifempty
    daily
    rotate 365
    create 0600 root root
    postrotate
        /usr/sbin/accton /var/account/pacct
    endscript
}

I found in one previous bug report regarding selinux and /tmp on tmpfs advice to
place "allow tmpfile tmpfs_t:filesystem associate;" in local.te and rebuild the
policy.  This helped to sort out some problem with previous version of policy,
but it doesn't seem to make any difference in this case.

Oh, I've just noticed, the output from "logrotate" command and kernel log are
from two different runs of logrotate.  I copy&pasted SELinux log from wrong
messages file.  I also have a line in messages file equivalent to the above
complaining about logrotate.y93Js1.

acct.te has been added to selinux-policy-targeted-1.23.18-1.