One more report, sorry...
As the title says. If you put "1234" in the ut_field of the utmpx,
call pututxline() and then read it back, you get "123" back. An od(1)
dump of the utmp file shows that what is stored is 1, 2, 3 and \0.
This is a problem for example with ssh (OpenSSH to be precise, I
Attached is a patch for the approach I suggested previously.
I only did some ad-hoc testing with the only 2 programs that both read
and write to utmp and that I have integrated with utmps: util-linux
login and OpenSSH. And I used the simple tests I attached earlier. All
good.
login is happy,
On Sun, Apr 11, 2021 at 2:31 PM Laurent Bercot wrote:
>
> Fixed in git, please try it and tell me if it works for you.
> (I simply made the getutx*() functions stay on the current record on
> success, instead of pointing to the next record.)
>
Thanks for the quick changes.
So the good news is
On Sun, Apr 11, 2021 at 9:53 PM Guillermo wrote:
>
> Ah, I see. There has to be a static library involved.
Yes, but to be extra clear and to avoid any confusion: your statement
is accurate only as far as it pertains specifically to skarnet
packages, libraries and build scripts. And this point is
El dom, 11 abr 2021 a las 15:03, Xavier Stonestreet escribió:
>
> [...] the breaking point
> is making strip and static linking with packages that are build-time
> dependencies. So for example, make strip skalibs and then statically
> link all other skarnet packages with it. Or make strip execline
On Sun, Apr 11, 2021 at 6:01 PM Guillermo wrote:
>
> I guess this executable stack thing is toolchain- / libc-specific?
It's dependent on the build procedure and/or the toolchain.
> The
> relevant test is using 'readelf -l' to check if there is a GNU_STACK
> program header, and that its flags
All my packages, in their git head, now have their Makefile fixed (by
not stripping .note.GNU-stack) and configure changed to not force
noexecstack, so it all defaults to what the toolchain does.
(And indeed the toolchains I was using were bad, because I stripped
.note.GNU-stack from the libc
Hello,
El vie, 9 abr 2021 a las 11:02, Xavier Stonestreet escribió:
>
> I did some more investigation and the problem lies
> in the Makefile's strip instructions which remove the GNU-stack
> section from the object files. Without the GNU-stack section the
> linker reverts to its
Fixed in git, please try it and tell me if it works for you.
(I simply made the getutx*() functions stay on the current record on
success, instead of pointing to the next record.)
--
Laurent
What's your take on this? My interpretation of the POSIX doc is that
pututxline(3) should start searching from the last entry found/read,
not from the next entry after it.
Well, yes, as you said, the spec is unclear, but the login(1) and
glibc interpretation makes sense: after a getutxline()
Hi,
I'm modifying util-linux's login(1) to work with utmps. Specifically
to update the database on logout, directly without relying on
s6-linux-init-logouthookd.
I'm piggybacking on the existing login.c code that updates the entry
possibly previously created by getty(8) or telnetd or whatever.
11 matches
Mail list logo