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
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.
Fixed in policy-1.9.1-1
confirmed the working. Thanks!
this problem appears again. I've tested this on policy 1.11.2-8. reopening
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.
I went ahead and did 2) for now. Comments still welcome. I don't think the procps maintainer will like the patch...