libutempter.so (bug 140308)

[Martin von Gagern]

Hi!

utempter is for writing records to utmp and needed for e.g. kwrited to
function. There are two implementations, one called utempter, which
seems to be unmaintained and therefore deprecated, and one called
libutempter which is under active development. They both work the same
way, by providing a library libutempter.so and a suid root binary that
will be called by functions from this library. While the library
interface is backward compatible, the binary arguments have changed.
Currently kpty calls the binary directly, assuming the old interface.

The patches I provided in http://bugs.kde.org/show_bug.cgi?id=140308 and
http://bugs.kde.org/show_bug.cgi?id=112840 solve the issue by linking
against the library instead of calling the binary. Now I finally managed
to contact Oswald on IRC and found out he is worried about adding
another library dependency. He referred me to a discussion here, I guess
he meant http://lists.kde.org/?l=kde-core-devel&m=117396431425132 .

Now I can see several possible solutions.

1. Leave it as is, depend on deprecated utempter
Will break utempter support on most distros. Won't work on FreeBSD.

2. Change calls to binaries to new interface
Will break compatibility with old utempter. If you use configure to
detect version and #ifdefs in the code, you are still in trouble if user
changes the implementation. Also not good for forward compatibility.

3. Detect installed binary
It might be possible to identify the installed utempter version at
runtime by some dark magic, and to call the binary accordingly. Would
rely heavily on undocumented features, reducing compatibility and
portability.

4. Link to libutempter.so
Patches exist. Very compatible solution. An additional library will
cause some overhead, and only very few applications seem to actually
need this utempter support.

5. Dynload libutempter.so
Would help in avoiding overhead for apps that don't need it. Oswald said
this might become simpler with recent klibrary stuff, so I assume this
solution might be less attractive for KDE 3.5 than for 4.

6. Move libutempter.so dependency closer to application
It seems that only very few applications would need utempter support,
while many applications depend directly or indirectly on kpty. It might
be possible to move the invocation of utempter functions directly into
the applications that need it or at least into some library used less
often. I don't know if this might break some overall design.

My personal order of preferences would be 4 5 6 2, from best to worst.

It might even make sense to choose different solutions for 3.x and 4.x,
like 4. for 3.x because it's easy to apply the patch and 5. for 4.x
because there dynloading is easier to implement.

Opinions?
Anyone willing to help, as I don't know enough to implement 5. or 6.?

 Martin von Gagern
(known as MvG on freenode IRC)