ports/86663: xterm-205 fails to write utmp entries for normal users
Jukka A. Ukkonen
jau at iki.fi
Wed Sep 28 06:20:19 UTC 2005
>Number: 86663
>Category: ports
>Synopsis: xterm-205 fails to write utmp entries for normal users
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Sep 28 06:20:17 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator: Jukka A. Ukkonen
>Release: 4.11-STABLE
>Organization:
private citizen
>Environment:
FreeBSD mjolnir 4.11-STABLE FreeBSD 4.11-STABLE #0: Wed Sep 21 07:56:19 EET DST 2005 jau at mjolnir:/home/src/sys/compile/Mjolnir i386
>Description:
Xterm-205 seems to write the utmp entries just fine when I
use the identity of root to start a new xterm.
When the xterm window starts with normal user rights it fails
to update utmp even though the xterm binary is suid root.
Could this be a sign that xterm drops the suid root access
a bit too early returning to the real uid before it has had
a chance to modify utmp?
The result does not change by adding +ut/-ut on the command
line. Except of course that even root then does not get an
entry in utmp.
So, this is not simply a reversed default value for a flag.
>How-To-Repeat:
Install xterm-205 and launch a new xterm. Check the /var/run/utmp
contents (simple who will do fine) to notice that the entry for the new
terminal session is missing.
>Fix:
Probably easily fixed by moving the code which drops root suid rights
a bit later in the code.
This is also why I classified this high/serious. The problem is probably easy
and quick to fix. OTOH its implications to system management can be very harmful.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-ports-bugs
mailing list