Am So., 1. März 2020 um 18:39 Uhr schrieb Taeer Bar-Yam <ta...@bar-yam.me>: > > Given that this has come up for two separate people, and I couldn't find > this bug report until after I'd been messing around for a long time, and > found the "bug" / solution separately, is it worth documenting this in a > comment in the code? > > I think the confusion largely comes from the fact that utempter provides > a binary, that really makes no sense to use on it's own (i.e. not > through libutempter). I've never seen this done before, and it feels highly > unintuitive to me. >
The calling process normally does not have permission to edit the utmp file. That's the reason for the setgid binary utempter to have a privilege separation. > > So maybe that fact is worth putting in a comment at the top of the > utempter binary source file? Or detecting when people are trying to use > it that way and printing out an error message? > Currently the error reporting is hidden due to a not defined macro (UTEMPTER_DEBUG). I though about adding a patch logging errors via syslog(3). > > I don't feel strongly about this, I just thought it was worth putting > out there. > > --Taeer > > Excerpts from Christian Göttsche's message of March 1, 2020 5:50 am: > > Control: tags -1 wontfix > > > > Hi, > > > > thank you Dmitry for your insights. > > I think the point is that one must not be able to tamper with > > pseudo-termial one does not own. > > > >> utmp_wrap /bin/bash -l > > > > To get this wrapper working, you can open a master pseudo-terminal > > yourself with posix_openpt(3) and pass that file descriptor to the > > libutempter functions. > > > >> That said, does anyone know if there are bigger security holes opened up > >> by this? How much of a problem is it if someone spoofs a `utmp` entry? > >> Why should I care? > > > > I am not aware of any, but I'd rather not enable tampering with > > entries of other users etc. > >
