Bug 119546

Summary: w doesn't show /dev/ttyn things in the enforcing mode
Product: [Fedora] Fedora Reporter: Akira TAGOH <tagoh>
Component: policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED NEXTRELEASE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: pgraner, russell, sdsmall
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.9.1-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-04-19 20:59:58 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: 114961    

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...