Bug 869176 - Blocking and dontauditing write to user_tmp while append is allowed is confusing
Blocking and dontauditing write to user_tmp while append is allowed is confusing
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.4
All Linux
unspecified Severity low
: rc
: ---
Assigned To: Miroslav Grepl
Michal Trunecka
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-23 04:13 EDT by Michal Trunecka
Modified: 2014-09-30 19:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-23 08:22:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Trunecka 2012-10-23 04:13:02 EDT
Description of problem:

This does not work (tempfile is created, but nothing is written in it):
restorecon /path/which/doesnt/exist 2> /tmp/tempfile
But this works fine (tempfile contains warning message):
restorecon /path/which/doesnt/exist 2>> /tmp/tempfile

This is caused by selinux, but no AVC messages are audited even in permissive mode, only when dontaudit rules are disabled (semodule -DB) is audited following AVC:

time->Tue Oct 23 10:08:47 2012
type=PATH msg=audit(1350979727.032:244): item=1 name=(null) inode=2946 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
type=PATH msg=audit(1350979727.032:244): item=0 name="/sbin/restorecon" inode=133853 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:setfiles_exec_t:s0
type=CWD msg=audit(1350979727.032:244):  cwd="/root/policycoreutils/Regression/bz824779-restorecon-does-not-return-proper-exit-codes-on"
type=EXECVE msg=audit(1350979727.032:244): argc=2 a0="restorecon" a1="/tmp/dir/that/does/not/exists"
type=SYSCALL msg=audit(1350979727.032:244): arch=c000003e syscall=59 success=yes exit=0 a0=159a9c0 a1=159c300 a2=14d48f0 a3=7fff355a00a0 items=2 ppid=3537 pid=3652 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="restorecon" exe="/sbin/setfiles" subj=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1350979727.032:244): avc:  denied  { write } for  pid=3652 comm="restorecon" path="/tmp/tmp.Zms0Z5VRD2" dev=dm-0 ino=6546 scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file



Version-Release number of selected component (if applicable):


How reproducible:
always

  
Actual results:
denied and dontaudited write while append is allowed

Expected results:
Allowed write or audited denial

Additional info:
Comment 1 Miroslav Grepl 2012-10-23 08:22:57 EDT
This is correct. We don't want to allow write. But some apps need "append" and this is a reason why we allow it. You "just" do "append".

Note You need to log in before you can comment on or make changes to this bug.