audit(1079205620.091:0): avc: denied { getattr } for pid=4269 exe=/usr/sbin/tmpwatch path=/tmp/foo dev=hda2 ino=212920 scontext=system_u:system_r:tmpreaper_t tcontext=system_u:object_r:file_t tclass=file audit(1079205620.271:0): avc: denied { unlink } for pid=4269 exe=/usr/sbin/tmpwatch name=before.new dev=hda2 ino=1357435 scontext=system_u:system_r:tmpreaper_t tcontext=system_u:object_r:file_t tclass=file
On Sun, 14 Mar 2004 06:40, Aleksey Nogin aleksey@nogin.org wrote:
audit(1079205620.091:0): avc: denied { getattr } for pid=4269 exe=/usr/sbin/tmpwatch path=/tmp/foo dev=hda2 ino=212920 scontext=system_u:system_r:tmpreaper_t tcontext=system_u:object_r:file_t tclass=file audit(1079205620.271:0): avc: denied { unlink } for pid=4269 exe=/usr/sbin/tmpwatch name=before.new dev=hda2 ino=1357435 scontext=system_u:system_r:tmpreaper_t tcontext=system_u:object_r:file_t tclass=file
If you have such files existing in /tmp then you have a problem. Allowing an unlink of file_t files is probably OK, I'll add that to my tree. But the case for file_t directories is more difficult. We don't want to allow tmpreaper to go wildly removing trees of files labeled file_t. The issue is the same as for home_type.
On 13.03.2004 20:47, Russell Coker wrote:
If you have such files existing in /tmp then you have a problem.
You know, I am starting to think that they probably stayed around across a setfiles invocation, and it would not happen with a stable policy. Sorry about the confusion.
Allowing an unlink of file_t files is probably OK, I'll add that to my tree.
Would it be a better idea to change how file_contexts marks files in /tmp and see whether that is sufficient?
On Sun, 14 Mar 2004 17:36, Aleksey Nogin aleksey@nogin.org wrote:
Allowing an unlink of file_t files is probably OK, I'll add that to my tree.
Would it be a better idea to change how file_contexts marks files in /tmp and see whether that is sufficient?
Not all existing files in /tmp will be labeled by setfiles. The problem is that you have multiple users who may put files in /tmp, and determining which user is responsible for a particular file is inconvenient. I guess we could have a program that looks at the UID of a file and then assigns it a type based on the role(s) that are permitted for the user who's name matches the UID. But this is ugly, and I expect that we will find cases of SETUID/SETGID programs creating files in /tmp that will cause problems with this if we try implementing it.
This is why we are looking at removing files from /tmp as part of a file system label.
On 14.03.2004 05:59, Russell Coker wrote:
This is why we are looking at removing files from /tmp as part of a file system label.
Yes, this seems reasonable (provided it makes sure that there are no user processes running on the system before doing it).
selinux@lists.fedoraproject.org