Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 119533 - konsole sessions not recorded in utmp
konsole sessions not recorded in utmp
Product: Fedora
Classification: Fedora
Component: policy (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: SELinux
Depends On:
Blocks: 122683
  Show dependency treegraph
Reported: 2004-03-31 00:52 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-07-20 08:36:12 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-31 00:52:47 EST
It I start konsole, then "w" would show me that session. In enforcing
mode neither recording the session, not reading it (e.g. if I start
the konsole in the permissive mode and then try running "w" in
enforcing one) works. However I do not get anything in the logs
(neither in enforcing mode nor in permissive one)...

I am running as staff_r and the full list of uncommented entries in my
tunable.te is given below:

Comment 1 Daniel Walsh 2004-03-31 08:25:22 EST
# Some shells ask for w access to utmp, but will operate
# correctly without it.  Do not audit write denials to utmp.
dontaudit $1_t initrc_var_run_t:file { getattr read write };

Looks like it is by design.   I will forward this bug to the NSA and
get their comments.

Comment 2 Stephen Smalley 2004-03-31 08:39:32 EST
IIRC, the library functions for accessing utmp (e.g. getutent) always
try to open utmp read-write, and then fallback to opening it read-only
if that fails.  So you can't necessarily assume that an audit message
that shows a read/write denial actually means that write access was
required for application to function (in many cases, the application
just wanted to read an entry).

In the case of kconsole, if it is normally allowed to update utmp,
then it is reasonable to put it into a domain that can write to it, as
has been done for other programs like utempter.  But you don't want to
directly allow the user domains to write to utmp, for obvious reasons.

Added Russell to the CC list, as this is a policy issue.

Comment 3 Daniel Walsh 2004-04-01 13:13:09 EST
Fixed policy to allow w to work.  Not going to fix writing to wtmp
file for now.
Comment 4 Aleksey Nogin 2004-04-07 21:47:33 EDT
w still does not work:

% w
 18:51:27 up 1 day,  6:18,  0 users,  load average: 0.31, 0.49, 0.34
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
% sudo w
 18:51:32 up 1 day,  6:19,  1 user,  load average: 0.29, 0.48, 0.33
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
aleksey  pts/12   xxxxxxxxxxxxxxxxx 18:48    0.00s  0.15s  0.03s sshd:
aleksey [priv]
% rpm -q policy-sources
% dmesg|tail -1
audit(1081389087.528:0): avc:  denied  { lock } for  pid=10752
exe=/usr/bin/w path=/var/run/utmp dev=hda2 ino=179875
tcontext=system_u:object_r:initrc_var_run_t tclass=file
Comment 5 Stephen Smalley 2004-04-08 07:20:04 EDT
Add 'lock' to the existing allow $1_t initrc_var_run_t:file { getattr
read }; rule in user_macros.te.  This should allow read-locking of the
Comment 6 Daniel Walsh 2004-04-08 09:42:45 EDT
Fixed in policy-1.10.1-4
Comment 7 Aleksey Nogin 2004-05-06 21:37:45 EDT
w still does not work. Strace shows

open("/var/run/utmp", O_RDWR)           = -1 EACCES (Permission denied)
open("/var/run/utmp", O_RDWR)           = -1 EACCES (Permission denied)
Comment 8 Stephen Smalley 2004-05-07 08:52:50 EDT
w shouldn't require write access to utmp, and even if we allowed it in
the policy, the Linux DAC permissions would prevent it.  It does
require read access, and that is allowed by the current policy.  The
library functions attempt to open rw initially, but fall back to
rdonly if that fails.  If I do a strace w, then I see the O_RDWR fail,
but it then proceeds to open O_RDONLY, and that succeeds.  However,
you are correct that w doesn't display any entries from user_t, and
I'm not sure why.  Possibly w doesn't gracefully handle the fact that
are denying access to the /proc/pid entries for other domains?  That's
the only difference I see.  But it can read the /proc/pid entries for
the same domain, so it should be able to get the information it needs.
Comment 9 Daniel Walsh 2004-07-20 08:36:12 EDT
Fixed in Rawhide

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