Version: (using KDE KDE 3.5.5) Installed from: FreeBSD Ports OS: FreeBSD When a KDE user starts and application like konsole KDE attempts to create a UTMP entry for a new terminal/login. To do this usually a root privilege or a suid bit is required. Typically KDE programs are not installed with suid bit set and frequently they are executed as a regular user. To work around the above limitations KDE has a capability to run an external program - utempter - that is installed suid and which can perform necessary UTMP updates. This capability is implemented in kdecore/util/kpty.cpp file. On the other hand this approach has some limitations. For example, path to "utempter" program can be different on different platforms and now it is hardcoded to /usr/sbin. Also, command line options of utempter may change and differ too. To make it easier to use utempter a wrapper library, libutempter, was developed. E.g., see: http://www.redhat.com/archives/fedora-maintainers/2006-July/msg00395.html I think that KDE libs should use the library in favor of the program. I have a patch that makes UTMP registration work on FreeBSD if sysutils/libutempter port is also installed.
Andriy, Care to share the patch? (: Fedora, which uses libutempter, has the same problem.
Created attachment 19335 [details] propsed patch for libutempter This is a proposed patch. It shows that using libutempter is much cleaner and easier. I am not very sure about autoconf-y part though. I.e. I am not really sure how to properly detect libutempter presence and which Makefile.am/Makefile.in should be patched to add libutempter as a dependency.
Couple more notes: 1. the patch was written against KDE version before kpty.c was moved 1 level down to .../utils/. 2. using d->slaveFd in libutempter call was a right thing for FreeBSD, but I am not 100% if this is universal. 3. definition of KProcess_Utmp class can be thrown out as well.
Created attachment 19336 [details] propsed patch for libutempter This is a proposed patch. It shows that using libutempter is much cleaner and easier. I am not very sure about autoconf-y part though. I.e. I am not really sure how to properly detect libutempter presence and which Makefile.am/Makefile.in should be patched to add libutempter as a dependency.
I think I can help out with any missing configure.in.in/Makefile.am bits. Thanks!
you should use utempter_remove_record() instead of utempter_remove_added_record() - the login might be done inside the child while logout is done in the parent, in which case libutempter cannot save the fd internally. anyway ... i'm wondering, what the advantage over just using utempter directly is?
fwiw, i'm asking about practical, not hypothetical advantages. in particular: * did the utempter iface ever change in an incompatible way? * does the iface provided by the lib stay the same? nope - there is already a deprecated one. * assuming new utempter features come along. how would we use them? right - through #ifdef-ery * how do we deal with systems with utempter but without libutempter? right, #ifdef-ery soo ... how is this better than what we already have? the path thing doesn't count, we can fix it independently.
Some info here: https://bugzilla.redhat.com/213369 On Fedora Core 6: # ls -ld /usr/libexec/utempter /usr/libexec/utempter/utempter drwx--x--- 2 root utempter 4096 Jan 16 22:24 /usr/libexec/utempter -rwx--s--x 1 root utmp 6944 Jul 27 23:25 /usr/libexec/utempter/utempter
See also related bug #112840
(In reply to comment #7): > * did the utempter iface ever change in an incompatible way? utempter (the original rpm) is afaik unmaintained for some time now. Even Fedora Core now uses libutempter, and the whole thing was a RedHat development all along as far as I know. So I'd consider the libutempter package the official replacement for utempter. I know Gentoo is trying to get rid of the old utempter package, from the bug mentioned in comment #8 I assume that FC has replaced it already. And the binary shipped with that already has a different interface, e.g. "add" instead of "-a" as an argument to add new records. So I'd answer your question with yes, the interface has changed in an incompatible way, at least if you talk to the binary directly. > * does the iface provided by the lib stay the same? > nope - there is already a deprecated one. The deprecated interface comes from the old utempter package. So even on systems that havent switched from utempter to libutempter, there is a library libutempter which provides this old interface. In that sense the library interface, in contrast to the executable interface, has stayed the same even across those two implementations. The new interface seems to be more of a simplification, and I personally doubt that the deprecated interface will be removed any time soon. So again I'd answer yes, the interface has stayed backward compatible, although it has been extended and the documentation suggest the use of this extension. > * assuming new utempter features come along. how would we use them? > right - through #ifdef-ery Or not at all, unless you actually need them. The same is true for the binary. However, when using the library, any change in features could be implemented by choosing new method names, causing the application to fail in obvious ways when the library does not match (e.g. after a downgrade). With an incompatible executable, you have no easy way of recognizing this fact, resulting in bugs that are difficult to notice and locate. I'd prefer the failfast nature of a missing function instead of an obsucrely failed call to an executable. So yes, you are right, to make use of new features while staying compatible to old implementations, we'd need #ifdef-ery -- whether we use library or call the executable directly. Unless you want to parse the usage information and call the executable accordingly. > * how do we deal with systems with utempter but without libutempter? > right, #ifdef-ery No need for that. You can use the old interface, which has been present in utempter as well and stays available in libutempter. This is what the configure script actually checks for even now, although the code doesn't use the library and function call after configure has checked its existence. Have a look at bug #112840 comment #10; there you will find a patch using the "old" interface, which makes things work with old utempter as well as new libutempter, and which won't rely on the executable directly. I've compared my patch to the one suggested in comment #4. My patch uses LDFLAGS, because the LIBADD seems to be mostly *.la files, whereas the configure script emits a -lutempter switch. But your patch here uses LIBADD. I'm not experienced with autotools. What's the difference; where should it go? Furthermore, my patch uses d->masterFd, as this was the fd used in the direct call to the binary. Your patch here changed masterFd to slaveFd. What is the rationale behind this? And of course I have a patch using the old interface, where your patch here only uses the new interface, breaking backwards compatibility. I think we should somehow merge this bug here and bug #112840. And maybe remove "newer" and "old" from the subject, as the new library also calls a program, and the old package also contained a libutempter library. So if you implement the old interface, it's only about using libutempter instead of the utempter program, no matter what implementation you actually use. And I don't think it is specific to FreeBSD either, but to any distro switching from the old implementation to the new one.
OK, I read a bit of automake info pages and think that LIBADD is the wrong variable since it is about adding elements to the library, not about adding libraries to the dependency list. I also looked at the master/slave issue. The libutempter header file explicitely states that argument as master_fd. And both implementations of the utempter executable call ptsname on the corresponding fd, indicating it has to be a master. Those two results indicate that, unless I missed something, my patch is correct the way it is right now. Should I append it here again, maybe as a patch against the svn trunk? There still remains the issue that according to comment #3 we should use slaveFd instead of masterFd on FreeBSD. I noticed that the FreeBSD port uses the same sources as my Gentoo. However it might not use ptsname but ttyname instead, as the code in utempter.c is this: #ifdef __GLIBC__ device = ptsname(STDIN_FILENO); #elif defined(__FreeBSD__) device = ttyname(STDIN_FILENO); #endif /* __GLIBC__ || __FreeBSD__ */ I don't know enough about ttyname, and haven't got a FreeBSD around to test this. I also don't understand why it doesn't use ptsname whenever possible; it is not a glibc extension but part of POSIX.1-2001 and present in FreeBSD at least since 5.1 according to the man page http://www.freebsd.org/cgi/man.cgi?manpath=FreeBSD+5.1-RELEASE&query=ptsname My guess is that the FreeBSD implementation of libutempter is somehow wrong, at least if it doesn't work equally well when passing the masterFd. I'll try to contact the libutempter maintainer about this.
I confirm there is a libutempter-on-FreeBSD issue. libutemper (as well as its prototype, utempter) was originally developed for GNU/Linux. About 1.5 years ago I applied (based on common sense because I'm not familiar with FreBSD) a patch from Gentoo developers to get FreBSD support, and one hunk (use of ttyname(3) instead of ptsname(3) on FreeBSD) now seems to be wrong. I'd like to hear a comment on this subject from FreBSD people.
Created attachment 19828 [details] Patch against trunk using old backwards compatible interface libutempter-1.1.5 is out and should solve the FreeBSD issue. Besides, afaik the old utempter never worked with FreeBSD anyway, so we won't be off any worse even if it should not work there yet. As the README now clearly states that the old interface is going to stay, I can see no reason not to use it and stay compatible to the old utempter, without calling its binary directly. I checked a set of modifications against trunk to make sure that a) utempter support is detected, b) everything compiles and c) things really link against libutempter and got a positive answer for each check. Therefore I'd like to see this patch here applied to trunk and attachment #17031 [details] applied to 3.5.
Hello, This patch works for me... Any reason why not closing this bug?
the patch is still pending, because linking an additional library for this tiny feature will probably cause an uproar (yes, i know it's small - but this matters only to 50%). an option would be to load the lib on demand. sounds a bit overengineered, but maybe it's the only acceptable option.
SVN commit 747237 by ossi: use libutempter instead of crafting own code. BUG: 140308 M +7 -1 ConfigureChecks.cmake M +1 -1 kpty/CMakeLists.txt M +6 -26 kpty/kpty.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=747237
Sorry to say but I believe this is again broken on 3.5.10. I can't seem to wall anything.
(In reply to comment #17) > Sorry to say but I believe this is again broken on 3.5.10. Not again: afaik this wasn't ever fixed in any 3.x branch, only in trunk before 4.0 was branched off it. So it's fixed in KDE 4, but not in KDE 3. As IO'd personally consider KDE 4 not ready for most end users, I would welcome having one of the patches from bug 112840 applied to the 3.5 branch. Should there be a separate bug for this? Or should we use bug 112840 or this one here?
Martin, Although I honestly don't understand the problem since I'm not a developer and frankly the inner workings of utempter and how it workd with kdelibs is above my skill level, what I can do is (at least for Gentoo users), post the patch into a modified ebuild and post it as a gentoo bug and hopefully it will get included into portage. If you can create a patch here that will work with kdelibs 3.5.10, I will try to do the rest.
Martin, I just realized you are a gentoo user (sorry!!), I just looked at the ebuild for kdelibs3.5.10 and there seems to be a patch there but it doesn't work, nor do wall messages show up when using kdm, I'm not sure of what the fix is, possible to use utempter instead of libutempter?
I'm wondering if the way to fix this is 1- unmerge libutempter, xterm 2- re-emerge xinit with -minimal use flag 3- emerge utempter && re-emerge kdelibs 3.5.10 with -utempter use flag? (then what happens with the patch that is already in the ebuild?)
*** Bug 112840 has been marked as a duplicate of this bug. ***
Comments 19 through 21 were a different issue, involving utmp permissions on Gentoo, filed there as 240164. Not a KDE bug. The fix still isn't included in the 3.5 branch: http://websvn.kde.org/branches/KDE/3.5/kdelibs/kdecore/kpty.cpp?view=markup Now that bug 112840 (where the appropriate patch is attached) has been duped here, either this one would need to be reopened or a new one filed to address this. As Gentoo includes the fix on the distribution level, and getting the fix into trunk took about a year, I don't have the energy to prod devs for this myself.