After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 149534 - utempter support
utempter support
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
0.11.x
Other Linux
: Low enhancement
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-08-06 20:41 UTC by Mikhail Zabaluev
Modified: 2015-05-09 17:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
utempter support patch for vte 0.11.11 (applies to CVS HEAD ATM) (5.21 KB, patch)
2004-08-06 20:43 UTC, Mikhail Zabaluev
none Details | Review
add utempter support (1.74 KB, patch)
2005-03-12 16:56 UTC, Roman Kagan
needs-work Details | Review

Description Mikhail Zabaluev 2004-08-06 20:41:09 UTC
What follows is a patch to conditionally enable support for the utempter
library/helper (ftp://ftp.altlinux.ru/pub/people/ldv/utempter/) that performs
privileged utmp/wtmp updates. Utempter helps better lockdown of a system by
making the utempter helper the only access point (setgid) to a group (usually
named utmp) that has exclusive rights to update utmp and wtmp records. Access to
the helper itself is further restricted with directory rights to a dedicated
group (e.g. utempter), the idea being that only binaries such as xterm, rxvt
etc. would be made setgid to this group (in our case, it would be gnome-pty-helper).
This system has withstood testing and deployment in the ALT Linux distribution
and it works quite good.

Note that one behavioral change had to be introduced to gnome-pty-helper: when
compiled with utempter support, it keeps master pty descriptors open until the
pty's are closed. This can lead to exhaustion of the effective per-process limit
on open descriptors. However, when gnome-terminal is the app, the
gnome-pty-helper process shares the limit with the parent gnome-terminal process
which manages all the pty's without forking anyway. Even if the client app
forks, a reasonable number of open pty's would be much lower than any reasonable
per-process limit on open descriptors.
Comment 1 Mikhail Zabaluev 2004-08-06 20:43:21 UTC
Created attachment 30289 [details] [review]
utempter support patch for vte 0.11.11 (applies to CVS HEAD ATM)
Comment 2 Kjartan Maraas 2004-10-18 10:21:30 UTC
Review please?
Comment 3 Roman Kagan 2005-03-12 16:52:46 UTC
This sounds a bit strange: why do you want to use utempter _with_
gnome-pty-helper?  AFAICT the main goal of the latter exactly coincides with
that of the former, i.e. move the functionality requiring higher priviledges
into a separate suid or sgid binary.

I'm using a different patch which allows to use utempter _instead_ of
gnome-pty-helper.  Please comment.
Comment 4 Roman Kagan 2005-03-12 16:56:39 UTC
Created attachment 38602 [details] [review]
add utempter support

This patch adds support for utempter _in_place_ of gnome-pty-helper.
Developed for 0.10.17, applies to 0.11.x.
Comment 5 Mikhail Zabaluev 2005-03-13 01:23:30 UTC
Functionalities of utempter and g-p-h do not exactly overlap as far as I'm
concerned.
Comment 6 Mikhail Zabaluev 2005-03-13 01:27:45 UTC
See the original entry as it describes usage of utempter in a properly
configured system. Its concept and security architecture differs considerably
from g-p-h.
However, I might get behind on the latest changes in the utempter project.
Comment 7 Roman Kagan 2005-03-17 18:15:13 UTC
Care to elaborate?

AFAICT g-p-h serves two purposes:

1) provide support for opening of and setting permissions on pty devices;

2) log utmp/wtmp records.

On most modern systems (1) doesn't require special priviledges these days and
can be done by vte itself through getpt()/grantpt() and friends (and in fact
#ifndef VTE_USE_GNOME_PTY_HELPER branch works pretty well).

Now if g-p-h only delegates (2) to utempter, what will be left?
Comment 8 Mikhail Zabaluev 2005-03-17 23:16:41 UTC
Umm... lastlog?
Comment 9 Roman Kagan 2005-03-18 05:05:25 UTC
Updating lastlog needs elevated priviledges too.  Doing it in g-p-h will require
it to be suid, thus defeating the whole purpose of utempter.

One can argue that then lastlog functionality should be added to utempter
itself.  However, on a "properly configured system" lastlog is updated once per
login session (as opposed to once per tty line for [uw]tmp) and is usually done
via pam_lastlog PAM module.
Comment 10 Mikhail Zabaluev 2005-03-18 07:41:44 UTC
So, either utempter should be extended or the lastlog option should be dropped
from g-p-h and gnome-terminal.
The first patch is not so intrusive. The maintainers have the choice.
Comment 11 Roman Kagan 2005-03-18 08:58:09 UTC
xterm and KDE pty interface class KPty (used by konsole) are using utempter as
it is for ages, without lastlog, so I don't see why vte can't.

As for intrusiveness, I tend to disagree here.  The current vte provides a
configure option to disable g-p-h and works happily without it, except that
terminal sessions aren't reflected in [uw]tmp.  Then utempter takes away the
last raison d'être for g-p-h, hence my patch considers --enable-gnome-pty-helper
and --enable-utempter conflicting.  Is it because of this you call my patch
intrusive?
Comment 12 Mikhail Zabaluev 2005-03-18 19:00:49 UTC
No, it is intrusive because it drops a feature g-p-h has, namely lastlog updates.
Comment 13 Roman Kagan 2005-03-18 19:20:49 UTC
Let's get this straight.

If you want lastlog updates in g-p-h, you have to install it setuid or setgid,
and then you shouldn't use utempter: it makes no sense.

Alternatively, if you want to use utempter (as a number of apps do), you have to
omit lastlog support from vte, and then there's nothing for g-p-h to do.

Or am I missing your point?
Comment 14 Mikhail Zabaluev 2005-03-18 19:31:20 UTC
> If you want lastlog updates in g-p-h, you have to install it setuid or setgid,
and then you shouldn't use utempter: it makes no sense.

It may make sense when all access to utmp/wtmp in the system should be done via
utempter by a selected set of setgid-utempter binaries. This is the policy in
ALT Linux, for example. The original patch was meant to suit this policy _and_
keep lastlog updates for those who need them.
Comment 15 Roman Kagan 2005-03-18 19:56:58 UTC
Do you mean that lastlog on your system has less restrictive access rules than
[uw]tmp?  Sounds like a broken policy then, given that lastlog has essentially
the same information as [uw]tmp.

Normally it is used for login sessions only, and thus typically installed 0644
root.root, while [uw]tmp are installed 0660 root.utmp.
Comment 16 Roman Kagan 2005-03-18 20:03:50 UTC
At any rate other terminal emulators don't seem to mess with lastlog, so doing
it in vte would be inconsistent.
Comment 17 Mikhail Zabaluev 2005-03-20 09:08:42 UTC
Here is a comment from our system guru (in Russian):
http://lists.altlinux.org/pipermail/devel/2005-March/019259.html

Basically, you're right, letting vte modify lastlog is a weird decision.
Comment 18 Behdad Esfahbod 2007-11-28 12:39:51 UTC
Any conclusion here?
Comment 19 Roman Kagan 2007-11-29 23:27:09 UTC
[ Sorry I didn't follow up on this for so long ]

Not sure about the conclusion.

The original patch looks somewhat strange in that it preserves the gnome-pty-helper for unclear reason.  And, at the very least, it needs to get rid of suid on g-p-h.

Nor is my patch good enough.  The problem is the libutempter design: it forks-execs the setuid binary for every access to utmp.  While doing so, it fiddles with SIGCHLD handling, and thus confuses vte's own bookkeeping, especially in apps where multiple terminals are created in a single program instance.  E.g. gnome-terminal started to occasionally miss the children termination events, and leave the tab/window open even when the shell had exited.
Comment 20 Behdad Esfahbod 2007-11-30 02:39:45 UTC
(In reply to comment #19)

> Nor is my patch good enough.  The problem is the libutempter design: it
> forks-execs the setuid binary for every access to utmp.  While doing so, it
> fiddles with SIGCHLD handling, and thus confuses vte's own bookkeeping,
> especially in apps where multiple terminals are created in a single program
> instance.  E.g. gnome-terminal started to occasionally miss the children
> termination events, and leave the tab/window open even when the shell had
> exited.

Sounds like reason enough to do it in g-p-h then.
Comment 21 Paul de Vries 2008-08-20 17:02:47 UTC
I am still bitten by this issue. Users on gentoo that use vte (with gnome-terminal) are never visible in utmp and wtmp. This is because /var/run/utmp and /var/log/wtmp have 644 for permissions. See http://bugs.gentoo.org/show_bug.cgi?id=232365
Comment 22 Behdad Esfahbod 2008-08-20 17:13:05 UTC
(In reply to comment #21)
> I am still bitten by this issue. Users on gentoo that use vte (with
> gnome-terminal) are never visible in utmp and wtmp. This is because
> /var/run/utmp and /var/log/wtmp have 644 for permissions. See
> http://bugs.gentoo.org/show_bug.cgi?id=232365

Sure, the bug is not fixed.

Neither there is a conclusive patch yet.
Comment 23 Christian Persch 2015-05-09 17:28:48 UTC
Obsolete now that g-p-h has been removed.