Bug 119546 - w doesn't show /dev/ttyn things in the enforcing mode
w doesn't show /dev/ttyn things in the enforcing mode
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: policy (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
 
Reported: 2004-03-31 06:43 EST by Akira TAGOH
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: 1.9.1-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-19 16:59:58 EDT
Type: ---
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 Akira TAGOH 2004-03-31 06:43:53 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.6)
Gecko/20040312 Debian/1.6-3

Description of problem:
When I run the w command on the console in the enforcing mode, it
doesn't work properly-- actually loggin into /dev/ttyn is me as the
normal user. but I can't find meself out from the result of w. but it
works well in the permissive mode. so I guess the file contexts for
/dev/tty* may be wrong.

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


How reproducible:
Always

Steps to Reproduce:
1.login as the normal user in the enforcing mode.
2.run w
3.
    

Actual Results:  /dev/ttyn entries is hidden

Expected Results:  it should be shown

Additional info:
I couldn't find any avc messages related this, though
Comment 1 Stephen Smalley 2004-03-31 08:44:18 EST
Looks like an omission from the policy,
allow $1_t initrc_var_run_t:file r_file_perms;
in user_macros.te or base_user_macros.te.
Adding Russell to cc line, as this is a policy issue.
Side bar:  base_user_macros.te currently gives lock permission, this
seems like a bad idea.

Comment 2 Daniel Walsh 2004-04-01 13:13:46 EST
Fixed in policy-1.9.1-1
Comment 3 Akira TAGOH 2004-04-12 02:34:15 EDT
confirmed the working. Thanks!
Comment 4 Akira TAGOH 2004-04-19 02:52:45 EDT
this problem appears again. I've tested this on policy 1.11.2-8. reopening
Comment 5 Colin Walters 2004-04-19 16:45:13 EDT
Ok.  This happens because w.c looks through /proc for the PID of the
login process associated with their login.  Since user_t isn't allowed
getattr on local_login_t, this is denied.

It apparently does this because it's double-checking that the login
still exists.  So we could either

1) Allow users to stat local_login_t processes
2) Disable the code in w.c that looks for the login process, and just
accept that the information could be stale.

Any opinions on which would be better? I have a patch for 1), and a
patch for 2) should be pretty easy too.
Comment 6 Colin Walters 2004-04-19 16:59:58 EDT
I went ahead and did 2) for now.  Comments still welcome.  I don't
think the procps maintainer will like the patch...

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