GNOME Bugzilla – Bug 149534
utempter support
Last modified: 2015-05-09 17:28:48 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.
Created attachment 30289 [details] [review] utempter support patch for vte 0.11.11 (applies to CVS HEAD ATM)
Review please?
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.
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.
Functionalities of utempter and g-p-h do not exactly overlap as far as I'm concerned.
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.
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?
Umm... lastlog?
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.
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.
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?
No, it is intrusive because it drops a feature g-p-h has, namely lastlog updates.
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?
> 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.
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.
At any rate other terminal emulators don't seem to mess with lastlog, so doing it in vte would be inconsistent.
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.
Any conclusion here?
[ 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.
(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.
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
(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.
Obsolete now that g-p-h has been removed.