Bug 119546 - w doesn't show /dev/ttyn things in the enforcing mode
Summary: w doesn't show /dev/ttyn things in the enforcing mode
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: policy
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: FC2Blocker
TreeView+ depends on / blocked
 
Reported: 2004-03-31 11:43 UTC by Akira TAGOH
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version: 1.9.1-1
Clone Of:
Environment:
Last Closed: 2004-04-19 20:59:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Akira TAGOH 2004-03-31 11:43:53 UTC
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 13:44:18 UTC
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 18:13:46 UTC
Fixed in policy-1.9.1-1

Comment 3 Akira TAGOH 2004-04-12 06:34:15 UTC
confirmed the working. Thanks!

Comment 4 Akira TAGOH 2004-04-19 06:52:45 UTC
this problem appears again. I've tested this on policy 1.11.2-8. reopening

Comment 5 Colin Walters 2004-04-19 20:45:13 UTC
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 20:59:58 UTC
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.