utmp implementation

[dslm4515]

The Musl Libc does not have utmp functionality built-in like glibc.

Perhaps skarnet’s utmps should be built before coreutils? Without it, some commands like last will report /dev/null/utmp is not a directory

[firasuke]

Well here's the thing with utmp, utmpx and skarnet's utmps:

• utmp.h has been deprecated in 2001 in favor of utmpx.h

• On Glibc systems the former utmp.h is just an alias (or a symlink) for the latter utmpx.h

• On musl libc, utmps can be used to provide utmpx functionality - but not utmp (This means that applications like procps-ng either don't work properly (w shows nothing under musl with default no-op implementation), or fails to build (utmps provides utmpx.h but no utmp.h)

• utmps also uses a daemon as the only authority to manage the utmp and wtmp data, which is an extra service to consider

• you'll also need to remove the stub header utmpx.h (and maybe even utmp.h) provided by musl if you plan on using skarnet's utmps

• You'll also need to patch multiple software to support utmpx.h instead of utmp.h since utmps only provides the latter. Here's a list of packages using utmp h (that might require patching) that I compiled based on my experiments in glaucus:

  • autoconf
  • toybox (some pending tools)
  • gcc (in libsanitizer)
  • shadow
  • musl
  • util-linux (for agetty)
  • procps-ng (for w and whattime)

From the musl wiki FAQ:

Q: Why is the utmp/wtmp functionality only implemented as stubs?

• if the feature is implemented, you need to take additional measures to protect your user’s privacy
• in order to use the utmp/wtmp feature, you need a suid/sgid binary to modify the database, which opens the door for security issues:
• if you compromise those binaries, you can inject arbitrary data into the db, that other programs might interpret in exploitable ways
• that’s a HUGE risk to pay for the sake of a basically-useless and possibly-harmful “feature”

The only distribution I know of that has utmps fully working with s6, musl and many other packages is Adélie Linux, so be sure to check their patches and the way they're implementing it.

For further reading:

• https://gitlab.com/procps-ng/procps/-/merge_requests/67
• https://code.foxkit.us/adelie/packages/blob/master/system/procps/use-utmpx.patch
• https://irclogs.alpinelinux.org/%23alpine-linux-2019-03.log

Hope that helps.

[dslm4515]

@firasuke , oh no, that helps a lot!

I just stumbled into an APKBUILD from Adélie Linux that shows utmps and skarnet being used while building shadow:

LIBS="-lutmps -lskarnet" ./configure ...

Its good to know I can check Adélie Linux to see how can get a utmpx implementation working.

Now I know why when build utmps after MLFS, it's not used at all.

[firasuke]

Yup, there's also that.

Don't forget to examine the resulting executables using your ldd.

[dslm4515]

Looks like I found my first hurdle: inetutils.

Can't decide if i should drop inetutils. Personally, I use ifconfig instead of ip... maybe its time for me to learn to use ip

make[2]: Entering directory '/sources/inetutils-1.9.4/libinetutils'
  CC       logwtmpko.o
logwtmpko.c:35:1: error: conflicting types for 'logwtmp'
   35 | logwtmp (char *line, char *name, char *host)
      | ^~~~~~~
In file included from /usr/include/utmpx.h:11,
                 from logwtmpko.c:24:
/usr/include/utmps/utmpx.h:64:13: note: previous declaration of 'logwtmp' was here
   64 | extern void logwtmp (char const *, char const *, char const *) ;
      |             ^~~~~~~
make[2]: *** [Makefile:1468: logwtmpko.o] Error 1
make[2]: Leaving directory '/sources/inetutils-1.9.4/libinetutils'
make[1]: *** [Makefile:1491: all-recursive] Error 1
make[1]: Leaving directory '/sources/inetutils-1.9.4'
make: *** [Makefile:1428: all] Error 2

Created a patch to fix mismatch of types. Compile error goes away. Patch will be featured in MLFS-8.00

[dslm4515]

Completed mlfs-8.00 with utmp/utmpx implementation. Not sure how to test. elogind now no longer has error Failed to create inotify on /dev/null/utmp, ignoring: Not a directory

[firasuke]

Nice, now hit w and see if it reports back any user(s).

[firasuke]

Any updates on this? Did you try what I mentioned in the previous comment?

[dslm4515]

Sorry, I had some strange issues:
I am currently rebuilding mlfs-8.00 on i686, since I decided not only to add utmps, but also replace pkg-config with pkgconf and gettext with gettext-tiny... and building mlfs-8.00 on x86_64. I built musl-1.2.1 fine on the i686 system, but had compile time errors on the x86_64 system. Both systems are using a copy of the same patches, scripts, and sources.

The i686 system had already built the final system Musl libc and working on bzip2. The x86_64 system just finished it's tool chain and entered chroot. When building musl, one of the patches from Adelie Linux failed. Strange as same patch was used in the i686 build... So i try to compile Musl on the i686 system and patch also failed. Not sure why hours ago, patch did not fail. In the end, i had to modify the patch from Adelie Linux to salvage the build.

Now back to your question:

# w
 23:11:25 up 6 days, 11:44,  0 users,  load average: 0.41, 0.29, 0.25
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT

^ is this expected output?

[dslm4515]

... same output if i try same command on my Samsung Chromebook3 (GalliumOS 3.1)

[firasuke]

That's the known issue, w doesn't show available users.

Try running w on any working Linux system (also on Adélie) and compare outputs.

[dslm4515]

Just for reference, I booted an Artix Linux LiveCD and got a different output:

artix:[artix]:~$ w
 22:10:10 up 14 min, 1 user, load average:0.00, 0.22, 0.43
USER     TTY        LOGIN@    IDLE    JCPU    PCPU    WHAT
artix    tty1      21:59      0.00s   0.12s   0.01s   w

Artix uses Glibc though.

I'll try a liveCD of Adelie Linux next

[dslm4515]

I didnt want to waste a blank DVD to burn a 719MB LiveCD of Adelie Linux, so installed Adelie Linux on an old Thinkpad x61s. Yes, Adelie does output users when try w.

Looks like, my bootscripts are not correctly running utmps?

[firasuke]

Unfortunately, that seems to be the case.