Re: [gdm-list] Old sessreg, gdm utmpwtmp and utmp->ut_id

[Brian Cameron <Brian Cameron Sun COM>]

Maximiliano:

> I'm running a few thinclient servers that use gdm as xdmcp. Gdm while a nice
> xdmcp server fails to store utmpwtmp information for remote clients.
>
> Back in the days when gdm Presession called sessreg, I've to patch sessreg
> to store a hash of the display string in utmp->ut_id, as the id was what glibc
> used a "unique identifier" in the utmp file, and without the patch all the
> users in my network ended up with the same id, this caused commands like who,
> to list only the last login session, thus a pain to administer. The hash used had
> a very small collission rate, so, it worked quite nicelly. The patch was
> accepted in sessreg, so every other admin might not have noticed the problem.

GDM 2.20 and later uses the display name as the ut_id identifier.  Users
should not get the same value for ut_id unless they are using the same
display.  Is this a problem?  If so, could you explain in more detail
why?

> After upgrading to gdm 2.20, the code to update utmpwtmp was moved to gdm
> itself, and it's coded only for local users, remote users won't set ut_line or
> ut_id, so the same problem back again. Commands like who, would only report the
> last logged in user. In addition, gdm won't obtain the hostname, so, only the
> ip address is stored. Once again a pain to administed effectivelly.

That is not true.  Looking at the code, GDM 2.20 and later does set
ut_id to the display value regardless of whether the display is local or
remote.

GDM will set ut_line to the device name associated with the device.  It
will only not set it if the device name is NULL.  If the display device
is NULL, then it should set the value to the $DISPLAY.

The only special handling for remote displays is that ut_host should be
set to the hostname:$DISPLAY value if the session is associated with a
remote machine.

You seem to suggest that the above logic is not working for you.  If so,
we should find out why.  Is there a bug in the code, or are the various
"HAVE_UT_*" #defines not being set properly on your platform?

> So, once again, I'll need to fix this. I'm looking at the code of gdm 2.21,
> and it seems to have some remote users utmpwmtp registering, but it uses the
> first 4 char of the display, which is quite prune to generate collissions,

Note that the latest version of GDM is 2.28.0.  I would recommend
working with the latest code rather than the older 2.21 version.  Since
all development effort has moved to the new 2.28.0 version, it probably
does not make sense to spend much effort trying to fix older versions.
It is unlikely that there will be another release of the "old GDM"
(version 2.20) unless there is a very compelling reason (e.g. a security
issue).

The ut_id value is indeed defined in /usr/include/ut_id to be a 4
character long string.  Is the problem you have that the display
values are getting truncated so that you do not have unique values?

> also, the code of utmpx in glibc uses ut_id only optionally now, so it might be
> better to use ut_line as the "unique identifier", and forget about ut_id (it
> must be zeroed).

Note that GDM support for utmpx needs to work on a wide variety of
platforms.  I have concerns about changing this in ways that might cause
problems for downstream distros.

What do other display managers, and other programs which set utmpx
records do?  It probably makes sense for GDM to be consistent with other
programs.

Perhaps if there are certain use-cases where it makes sense to set utmpx
differently than normal, it might make sense to make it possible to
configure GDM to allow this.

> As POSIX defines ut_line as a 32 bytes long string (using utmpx, which gdm
> 2.21 is using), it might be needed to tweak the string a bit (making sure the
> display number is available, even with a long display string). I don't really
> know the status of vnc remote display or X11 disconnection support nor the
> display string those would generate, but when those are defined it might be
> needed to tweak the ut_line once again.
>
> Also, gdm_session_record_login and gdm_session_record_logout use getutxent to
> iterate over the utmp file, which is quite inefficient, as that's the job of
> getutxline.

Any changes that you want to propose to make the code run more
efficiently would likely be accepted upstream with no difficulty, 
assuming that they work well across different distributions.

> If everything sound fine to you, I'll prepare and send the patch.

It is not yet clear to me exactly what problems you are trying to solve.
Some of your analysis above does not seem correct to me.  For example,
you seem to suggest that ut_line and ut_id are not set for remote users,
which does not seem to match what the code does.

I also think we need to be careful to make an effort to not break how
utmpx is handled on different platforms.  So, any proposed changed
should be tested on a variety of platforms before being going upstream,
I'd think.

So, I think we need to discuss further.  A proposed patch would likely
help the discussion, and make it possible to do such cross-platform
testing.

Brian