Bug 237186

Summary: LSPP: writes to /selinux/avc/cache_threshold can enexpectedly succeed
Product: Red Hat Enterprise Linux 5 Reporter: Trevor Highland <tshighla>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED NOTABUG QA Contact: Martin Jenner <mjenner>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: iboverma, krisw, linda.knippers, ltcgcw
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-04-20 20:06:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 224041    

Description Trevor Highland 2007-04-19 21:27:31 UTC 
Description of problem:
Writes to /selinux/avc/cache_threshold succeed by users without write
permission, if the user tries to write the value currently in the file.

Version-Release number of selected component (if applicable):
  2.6.18-8.1.1.lspp.76.el5

How reproducible:
  This behavior can always be reproduced.


Steps to Reproduce:
1.
  Login with the staff_r role and become root.
2.
   cat /selinux/avc/cache_threshold
3.
   echo [current contents] > /selinux/avc/cache_threshold
   write succeeds.
4. echo [different value] > /selinux/avc/cache_threshold
   write error: permission denied

Actual results:
  Under a role without write access to a /selinux/avc/cache_threshold.  The
  user is able to write the value currently in the file without having the write 
  fail with a permission denied error.

Expected results:
  Any call to the write system call made by a user without write permission 
  should return EPERM.  It is misleading for writes to succeed because the value 
  in the file is unchanged.

Additional info:
Comment 1 Steve Grubb 2007-04-20 20:06:06 UTC 
I think this was discussed on the LSPP mail list and the group consensus was
that since this is a interface accessible only by an admin, its OK. Closing this
request.