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,
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
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
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()
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
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.
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
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 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
11 matches
Mail list logo
