Bug 802333

the given file is part of my users wine directory:
~/.wine/drive_c/windows/winsxs/x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_31a54e43

later there were SE alerts due to the same file for setattr instead of write access

and a little later alerts due to /usr/sbin/tmpwatch instead of /bin/systemd-tmpfiles concerning write access to ~/.wine/drive_c/windows/Microsoft.NET/Framework/v2.0.50727

=> seems like the SE policies for user wine folders are broken with respect to the recently changed tmp file handling of fedora 16

sorry for the confusion! the files are NOT in the users home directory!

about a month ago I moved my wine folder to /tmp/ to create a fresh ~/.wine and to reinstall some broken tools. I.e. I ran
   mv ~/.wine /tmp/wine_old

this backup copy (wine_old) obviously was just today old enough to be forgotten and systemd-tmpfiles as well as tmpwatch tried to get rid of these old files.

so neither systemd-tmpfiles nor tmpwatch delete files from users home folders by default (I was really kind of worried and confused...).
Anyways, I don't closes this bug as invalid, as I still think it's probably not intended behavior to get bombarded by SE alerts if you move a bunch of files to the tmp folder from a different security context.

besides that it's obviously confusing to see only the basename of the file in all the SE alert dialogs. If the absolute path would have been given at least once, I would have seen the real problem sooner

I am surprised this needs write and setattr.

the given paths were actually folders, so the write access might have been a try to remove files in this directory. May be systemd-tmpfiles tries to run something like chmod +w on the folder when it's not allowed to remove the files.

This would explain write and setattr on the given folders, but I'm not familiar with the internals of systemd-tmpfiles or tmpwatch, so it's just a wild guess

I've seen this with a 'krb5' directory:


SELinux is preventing /usr/bin/systemd-tmpfiles from 'write' accesses on the directory krb5.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that systemd-tmpfiles should be allowed write access on the krb5 directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep systemd-tmpfile /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:systemd_tmpfiles_t:s0
Target Context                unconfined_u:object_r:user_home_t:s0
Target Objects                krb5 [ dir ]
Source                        systemd-tmpfile
Source Path                   /usr/bin/systemd-tmpfiles
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           systemd-44-17.fc17.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-146.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.5.2-3.fc17.x86_64 #1 SMP Tue Aug
                              21 19:06:52 UTC 2012 x86_64 x86_64
Alert Count                   7
First Seen                    2012-09-02 07:13:12 CEST
Last Seen                     2012-09-03 11:21:46 CEST
Local ID                      941713be-84f6-43f5-a911-ca6ccfae9f8d

Raw Audit Messages
type=AVC msg=audit(1346664106.309:133): avc:  denied  { write } for  pid=3517 comm="systemd-tmpfile" name="krb5" dev="sda1" ino=411297 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir


type=SYSCALL msg=audit(1346664106.309:133): arch=x86_64 syscall=unlinkat success=no exit=EACCES a0=5 a1=27e6773 a2=200 a3=33a61b0778 items=0 ppid=1 pid=3517 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=systemd-tmpfile exe=/usr/bin/systemd-tmpfiles subj=system_u:system_r:systemd_tmpfiles_t:s0 key=(null)

Hash: systemd-tmpfile,systemd_tmpfiles_t,user_home_t,dir,write

audit2allow

#============= systemd_tmpfiles_t ==============
#!!!! The source type 'systemd_tmpfiles_t' can write to a 'dir' of the following types:
# device_t, var_auth_t, etc_t, file_t, tmpfs_t, man_t, root_t, config_home_t, tmp_t, usr_t, var_t, lockfile, pidfile, tmpfile, sandbox_file_t, faillog_t, var_spool_t, httpd_cache_t, var_log_t, var_lib_t, init_var_run_t, rpm_var_lib_t, httpd_sys_rw_content_t

allow systemd_tmpfiles_t user_home_t:dir write;

audit2allow -R

#============= systemd_tmpfiles_t ==============
#!!!! The source type 'systemd_tmpfiles_t' can write to a 'dir' of the following types:
# device_t, var_auth_t, etc_t, file_t, tmpfs_t, man_t, root_t, config_home_t, tmp_t, usr_t, var_t, lockfile, pidfile, tmpfile, sandbox_file_t, faillog_t, var_spool_t, httpd_cache_t, var_log_t, var_lib_t, init_var_run_t, rpm_var_lib_t, httpd_sys_rw_content_t

allow systemd_tmpfiles_t user_home_t:dir write;

Stef, 
did you move a dir to the /tmp dir?

I didn't move this directory explicitly there. But perhaps this was done by a script of some sort. I'll try and keep my eye out for it.