Hello
As of version 0.1.0.0, utmps' configure script ignores the
--with-xtmpd-socket options.
Here is a small patch that fixes it:
--- utmps-0.1.0.0/configure 2020-12-28 15:42:20.0 +0100
+++ utmps-0.1.0.0/configure.new 2021-04-08 06:07:33.268605048 +0200
@@ -201,11 +201,11 @@
--
Hello,
First I apologize if this is a FAQ. I searched this mailing list
archive and the interweb at large but didn't find anything relevant.
Recent versions of the Linux kernel issue a warning when a process
executes an image with an executable stack, as an indicator of a
_potential_ security vul
On Thu, Apr 8, 2021 at 2:25 PM Laurent Bercot wrote:
> What works is setting the attribute at the link level
> (-Wl,-z,noexecstack in LDFLAGS), and if it's not done, apparently
> GNU toolchains still mark the stack as executable by default in the
> binaries.
Yes that is effective at marking th
On Thu, Apr 8, 2021 at 9:57 PM Laurent Bercot wrote:
>
> My toolchain also creates E stack binaries by default, no matter
> whether they're static or dynamic. It may be that my build of musl is
> bad.
That's unexpected.
> I am not interested enough in the details of what happens at the ld
>
On Fri, Apr 9, 2021 at 5:06 AM Laurent Bercot wrote:
>
> To make things perfectly clear: the modification I pushed to git also
> applies to the ld invocations creating shared libraries, including
> libskarnet.so. So with that change, skalibs or libutmps will not
> pollute anything else. ;)
Soun
On Fri, Apr 9, 2021 at 3:46 PM Laurent Bercot wrote:
>
> Oh! That's interesting
Interesting, and very nasty:
"Fail open design
Since this is the default, the only way to get a non-executable stack
is if every object file input to the linker explicitly declares that
it does not need an executa
Hello,
Since UTMPX_FILE is already defined I figure its W counterpart might
as well be defined.
>From a logical standpoint, updwtmpx(3) and utmpxname(3) requires the
path to the wtmp file as an argument, but the location of wtmp is
non-standard and varies by platform. Some packages use WTMPX_FILE
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. Th
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 ar
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
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
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, Open
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 do
Thanks for sharing your thoughts - I appreciate, and learn from, your input.
Again I didn't mean to belittle or devalue your work, quite the
opposite. I'm disappointed and underwhelmed by the interface and its
usage, not by the implementation. Also referring to the s6 as an
"ecosystem" was silly,
On Tue, Apr 13, 2021 at 3:11 AM Laurent Bercot wrote:
>
> Please test the latest git head and tell me if it's working for you.
Yep, it's all good. Thanks for making the changes.
> Anyway, I changed utmps so that ut_id - and also ut_user and ut_line,
> for consistency - are treated as char ar
15 matches
Mail list logo
