ports/118218: x11/xterm should be configured with --enable-setuid for utempter to work

[Andriy Gapon]

>Number:         118218
>Category:       ports
>Synopsis:       x11/xterm should be configured with --enable-setuid for utempter to work
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 23 12:40:01 UTC 2007
>Closed-Date:
>Last-Modified:
>Originator:     Andriy Gapon
>Release:        FreeBSD 6.2-RELEASE-p6 amd64
>Organization:
>Environment:
System:
FreeBSD 6.2-RELEASE-p6 amd64
xterm-229
>Description:
New xterm sessions do not create utmp/wtmp records if libutempter is installed.

This happens because xterm is configured without --enable-setuid option and
with --with-utempter option. Despite the fact that port's Makefile makes
xterm mode suid, xterm itself drops priveleges too early and doesn't prepare
terminal for libutempter to work on it. (Doesn't change its ownership to
current uid).

The issue was discussed and confirmed with xterm's author Thomas Dickey via
private email and Kiril, the port's maintainer, was also notified about
this via private email as well.

Some excerpts from the emails:
=========== original report =======================================
...
I also have libutempter installed.

xterm is actually always being installed with set-uid bit set regardless
of what xterm configure decides, the port enforces this in its
post-install target.

As I can see in xterm configure.in script, availability of utempter
automatically means "disable setuid".

Here's some output produced with TRACE enabled in xterm main.c (plus
couple of added printf's) and also DEBUG enabled in utempter:
...
As I understand the first line means that setuid() is being called with
real user id and on FreeBSD this means that there is no going back - all
user ids (current and saved) are reset to the real one.
Thus its no wonder that xterm can not take ownership of a tty device.
utempter also refuses to do any bookkeeping if owner of tty and its real
uid do not match.

I think that even if we use utempter for utmp/wtmp recording we still
should not call disableSetUid too early so that xterm could always grab
ownership of its tty and the grab should be done before utempter call.
...
==================================================================
=========== concluding email from Thomas =========================
>How-To-Repeat:
1. install sysutils/libutempter
2. install xterm
3. run xterm as non-root user
4. neither 'w' nor 'last' report xterm session
5. also /dev/ptyX that xterm uses is not owned by the user
>Fix:
Add --enable-setuid option to configure arguments. Although it appears
as this is the default, it is not so when --with-utempter is used.

>Release-Note:
>Audit-Trail:
>Unformatted:
 >> >> ...but if you _explicitly_ set ---enable-setuid, the script is supposed
 >> >> to honor that request.  Here's the relevant chunk from configure.in:
 > > [snip]
 > >
 > > If I understand you correctly the FreeBSD port should pass
 > > --enable-setuid to configure ?
 
 yes - I think that's the answer.  I was using just the configure script
 rather than the port.  (I had iirc utempter 1.1.1 rather than the latest,
 but it seemed to work properly).
 
 ==================================================================