Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 119507 - [unlimitedUsers] staff_r can not run rpm? Should /usr/lib/rpm/rpmi and not /bin/rpm be rpm_exec_t
[unlimitedUsers] staff_r can not run rpm? Should /usr/lib/rpm/rpmi and not /b...
Product: Fedora
Classification: Fedora
Component: policy (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: SELinux
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
Reported: 2004-03-30 18:31 EST by Aleksey Nogin
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-07 07:40:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Aleksey Nogin 2004-03-30 18:31:55 EST
After the most recent (post-FC2t2) updates to the policy package,
staff_r (and, I am guessing, user_r too) can not run rpm - even "rpm
-q" or "rpm -V". This is IMO wrong. 

If there is a desire to prohibit staff_r from running rpm_exec_t files
(which is probably a good idea), then the /usr/lib/rpm/rpmi should be
marked as rpm_exec_t, while /bin/rpm should become an ordinary bin_t
(and should then always call rpmi for actual rpm installs/upgrades).
Comment 1 Bill Nottingham 2004-03-30 21:39:36 EST
Actually, *everyone* should be able to run rpm -q ; anything else
should be a tunable.
Comment 2 Daniel Walsh 2004-03-30 22:19:06 EST
I am not seeing this.  What avc messages are you getting?

Comment 3 Aleksey Nogin 2004-03-30 22:41:08 EST
That's the thing - I am not getting any, just the "Permission denied".

% rpm -q rpm
bash: /bin/rpm: Permission denied
% ls -l /bin/rpm
-rwxr-xr-x  1 rpm rpm 75760 Мар 16 09:10 /bin/rpm
% ls -lZ /bin/rpm
-rwxr-xr-x+ rpm      rpm      system_u:object_r:rpm_exec_t     /bin/rpm
% id -Z
% ls -lZ /usr/bin/yum
-rwxr-xr-x+ root     root     system_u:object_r:rpm_exec_t    
% yum
bash: /usr/bin/yum: /usr/bin/python: bad interpreter: Permission denied
% sudo rpm -q policy-sources
Comment 4 Daniel Walsh 2004-03-30 22:46:14 EST
Could you do a setenforce 0

Then execute the rpm -q command and see if you get any messages.

Are you on the #selinux chat room?

Comment 5 Aleksey Nogin 2004-03-30 23:35:59 EST
security_compute_sid:  invalid context aleksey:staff_r:rpm_t for
scontext=aleksey:staff_r:staff_t tcontext=system_u:object_r:rpm_exec_t
Comment 6 Daniel Walsh 2004-03-31 00:11:32 EST
For some reason you are attempting to transition to rpm_t.  You should
not be, for the staff user while not in unlimitedUsers.

Could you check to see if you have a domain_trans for staff_t to rpm_t?

Comment 7 Aleksey Nogin 2004-03-31 00:15:23 EST
Ah, I do have unlimitedUsers set.
Comment 8 Daniel Walsh 2004-03-31 00:20:07 EST
role staff_r types rpm_t;
If you want to run in unlimitedUsers you need to add the above line to
rpm.te where the transition code is.  I will fix this in the next
policy.  The unlimitedUsers role will be turned off in the next
policy, as we attempt to tighten up the security, in policy.
Comment 9 Aleksey Nogin 2004-03-31 00:34:41 EST
OK, I brough my tunable.te closer to the one currently distributed
(including commenting out the unlimitedUsers) and the problem went
away. Thanks!
Comment 10 Daniel Walsh 2004-03-31 10:09:16 EST
Fixed in policy-1.9.1-4

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