bug#20067: [PATCH] system: grub: Introduce foreign-menu-entry.

[Chris Marusich]

l...@gnu.org (Ludovic Courtès) writes:

> I still think that the approach proposed at
>  is more
> appropriate; ‘menu-entry’ would always work, no duplication would be
> necessary.
>
> As a stop-gap measure, I would prefer to (1) allow:
>
>   (menu-entry
> ;; …
> (linux #~(string-append #$kernel "/bzImage")))
>
> (2) remove the “/bzImage” assumption and use the above idiom everywhere
> in the current code, and (3) and have a hack along these lines to
> correctly interpret (string-append …) in the ‘parameters’ file:
>
>
> diff --git a/gnu/system.scm b/gnu/system.scm
> index d6bf6c4..467d907 100644
> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -766,7 +766,11 @@ this file is the reconstruction of GRUB menu entries for 
> old configurations."
>   (boot-parameters
>(label label)
>(root-device root)
> -  (kernel linux)
> +  (kernel (match linux
> +(('string-append (? string? strings) ...)
> + (string-concatenate strings))
> +(_
> + linux)))
>(kernel-arguments
> (match (assq 'kernel-arguments rest)
>   ((_ args) args)
>
>
> Thoughts?

Yes, that approach seems better to me.

-- 
Chris


signature.asc
Description: PGP signature

bug#24138: SIGSEGV of useradd (from shadow package)

[Tomáš Čech]

On Wed, Aug 03, 2016 at 06:56:19PM +0200, Ludovic Courtès wrote:

Hello!

Tomáš Čech  skribis:


It seems to be easy to crash useradd (from shadow package).


Is it on GuixSD?


Yes. \o/


from strace:

read(3, "account required pam_deny.so \nau"..., 4096) = 223
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_deny.so",
 O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\6\0\0\0\0\0\0"..., 
832) = 832
fstat(5, {st_mode=S_IFREG|0555, st_size=6728, ...}) = 0
mmap(NULL, 2100200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 
0x7fb8b447c000
mprotect(0x7fb8b447d000, 2093056, PROT_NONE) = 0
mmap(0x7fb8b467c000, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0) = 0x7fb8b467c000
close(5)= 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fb8b3d1bda8} ---


Could you check in the ‘strace’ output whether PAM modules build with
another libc are being loaded?


It doesn't seem to be that case:

# grep linux-pam ~/useradd.strace  | grep -v ENOENT
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam_misc.so.0",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_unix.so",
 O_RDONLY|O_CLOEXEC) = 4
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_rootok.so",
 O_RDONLY|O_CLOEXEC) = 4
19555 stat("/gnu/store/m4xna3zq2il5an61wxbmfv82ndvz70f6-linux-pam-1.2.1/lib", 
{st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_deny.so",
 O_RDONLY|O_CLOEXEC) = 5

On the other hand it seems to load part of the libraries from 2.22,
part from 2.23 and that is not healthy.

# grep glibc ~/useradd.strace  | grep -v ENOENT
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2", 
O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libc.so.6", 
O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/share/locale/locale.alias",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnss_compat.so.2",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnsl.so.1", 
O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnss_nis.so.2",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnss_files.so.2",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libcrypt.so.1",
 O_RDONLY|O_CLOEXEC) = 4
19555 stat("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib", 
{st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
19555 
open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libm.so.6", 
O_RDONLY|O_CLOEXEC) = 4
19555 
open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/librt.so.1", 
O_RDONLY|O_CLOEXEC) = 4
19555 
open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libpthread.so.0",
 O_RDONLY|O_CLOEXEC) = 4

It seems to be more serious than I thought:

# login
Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen])

S_W


signature.asc
Description: Digital signature

bug#24146: Various window managers need startup services.

[Ludovic Courtès]

Hi,

ng0  skribis:

> Is a service what is required to make them selectable (cycle by pressing
> F1) in the SLIM login?

No, all you need is to add them to the ‘packages’ field of the OS, as in
the example at (search for “lightweight window managers”):

  
https://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html#System-Services

HTH!

Ludo’.

bug#24146: Various window managers need startup services.

[ng0]

Hi,

Ludovic Courtès  writes:

> ng0  skribis:
>
>> We have gnome and xfce with services to start them in
>> gnu/services/desktop.scm.
>>
>> We should add services for:
>>
>> * xmonad
>> * awesome
>> * ratpoison
>> * windowmaker
>> * sawfish
>> * openbox
>> * guile-wm
>> * i3-wm
>> * evilwm
>> * dwm
>> * bspwm
>
> Unlike full-blown desktop environments (GNOME, Xfce, KDE), I don’t think
> any of these window managers needs a service, because they typically fit
> in one package with just one command that needs to be launched.
>
> Compare this with ‘gnome-service-type’, which needs to extend Polkit and
> to add a whole bunch of packages to /run/current-system/profile so that
> it can work.
>
> ratpoison doesn’t need anything like that.  :-)
>
> I’m closing this bug, but let me know if you think I’m overlooking
> something!
>
> Thank you,
> Ludo’.


Am I overlooking something then?

Is a service what is required to make them selectable (cycle by pressing
F1) in the SLIM login?
I know that they all can be started just with one command, but having
them in SLIM would make it more visible as long as we use SLIM.

We could also have system config parts for them, for example to make
the awesome-wm config adjustable in the system.
-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

bug#24145: [PATCH] gnu: asciidoc: Use local docbook-xsl package.

[Tomáš Čech]

* gnu/packages/documentation.scm(asciidoc): New input docbook-xsl,
  replace use of online source and prefer docbook-xsl package.
---
 gnu/packages/documentation.scm | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/documentation.scm b/gnu/packages/documentation.scm
index 72af708..98d30e7 100644
--- a/gnu/packages/documentation.scm
+++ b/gnu/packages/documentation.scm
@@ -49,8 +49,22 @@
(base32
 "1w71nk527lq504njmaf0vzr93pgahkgzzxzglrq6bay8cw2rvnvq"
 (build-system gnu-build-system)
-(arguments '(#:tests? #f)); no 'check' target
-(inputs `(("python" ,python-2)))
+(arguments
+ `(#:tests? #f ; no 'check' target
+   #:phases
+   (modify-phases %standard-phases
+ (add-before
+ 'install 'make-local-docbook-xsl
+   (lambda* (#:key inputs #:allow-other-keys)
+ (substitute* (find-files "docbook-xsl" ".*\\.xsl$")
+   (("xsl:import 
href=\"http://docbook.sourceforge.net/release/xsl/current";)
+(string-append
+ "xsl:import href=\""
+ (string-append (assoc-ref inputs "docbook-xsl")
+"/xml/xsl/docbook-xsl-"
+,(package-version docbook-xsl))
+(inputs `(("python" ,python-2)
+  ("docbook-xsl" ,docbook-xsl)))
 (home-page "http://www.methods.co.nz/asciidoc/";)
 (synopsis "Text-based document generation system")
 (description
-- 
2.9.2

bug#24146: Various window managers need startup services.

[Ludovic Courtès]

ng0  skribis:

> We have gnome and xfce with services to start them in
> gnu/services/desktop.scm.
>
> We should add services for:
>
> * xmonad
> * awesome
> * ratpoison
> * windowmaker
> * sawfish
> * openbox
> * guile-wm
> * i3-wm
> * evilwm
> * dwm
> * bspwm

Unlike full-blown desktop environments (GNOME, Xfce, KDE), I don’t think
any of these window managers needs a service, because they typically fit
in one package with just one command that needs to be launched.

Compare this with ‘gnome-service-type’, which needs to extend Polkit and
to add a whole bunch of packages to /run/current-system/profile so that
it can work.

ratpoison doesn’t need anything like that.  :-)

I’m closing this bug, but let me know if you think I’m overlooking
something!

Thank you,
Ludo’.

bug#24146: Various window managers need startup services.

[ng0]

We have gnome and xfce with services to start them in
gnu/services/desktop.scm.

We should add services for:

* xmonad
* awesome
* ratpoison
* windowmaker
* sawfish
* openbox
* guile-wm
* i3-wm
* evilwm
* dwm
* bspwm

And the ones I probably forgot due to bad keywords in their
description.
-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

bug#24136: libgcrypt 1.7.0 is not bit-reproducible

[Leo Famulari]

On Wed, Aug 03, 2016 at 02:50:00AM +0200, Ludovic Courtès wrote:
> The other file has a timestamp issue:

For reference, a discussion of the responsible code:
https://groups.google.com/forum/#!topic/linux.debian.bugs.dist/hjzVpYKCbr0

Unfortunately, that code ('doc/yat2m.c') is different across the various
GnuPG projects, so we can not take the patch directly from gnupg-2.1.

bug#24145: asciidoc depends on Internet connection instead of docbook-xsl package

[Tomáš Čech]

I'm trying to create package for sway and I noticed strange behavior
difference between build by daemon and by me within prepared
environment.

I found the reason for that - a2x (asciidoc) is trying to access
manpage/docbook.xsl.

asciidoc package needs to be adjusted to use docbook-xsl package files
instead so it could be used for build.



$ ag 'import.*docbook\.xsl' /gnu/store/*-asciidoc-*
/gnu/store/…-asciidoc-8.6.9/etc/asciidoc/docbook-xsl/xhtml.xsl
12:http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"/>

/gnu/store/…-asciidoc-8.6.9/etc/asciidoc/docbook-xsl/fo.xsl
16:http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl"/>

/gnu/store/…-asciidoc-8.6.9/etc/asciidoc/docbook-xsl/manpage.xsl
12:http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"/>

/gnu/store/…-asciidoc-8.6.9/etc/asciidoc/docbook-xsl/epub.xsl
12:  http://docbook.sourceforge.net/release/xsl/current/epub/docbook.xsl"/>


IMO, for these files it should be sufficient to replace:

http://docbook.sourceforge.net/release/xsl/current/

with

/gnu/store/…-docbook-xsl-*/xml/xsl/docbook-xsl-*/


S_W


signature.asc
Description: PGP signature

bug#24138: SIGSEGV of useradd (from shadow package)

[Ludovic Courtès]

Hello!

Tomáš Čech  skribis:

> It seems to be easy to crash useradd (from shadow package).

Is it on GuixSD?

> from strace:
>
> read(3, "account required pam_deny.so \nau"..., 4096) = 223
> open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_deny.so",
>  O_RDONLY|O_CLOEXEC) = 5
> read(5, 
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\6\0\0\0\0\0\0"..., 832) = 
> 832
> fstat(5, {st_mode=S_IFREG|0555, st_size=6728, ...}) = 0
> mmap(NULL, 2100200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 
> 0x7fb8b447c000
> mprotect(0x7fb8b447d000, 2093056, PROT_NONE) = 0
> mmap(0x7fb8b467c000, 4096, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0) = 0x7fb8b467c000
> close(5)= 0
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fb8b3d1bda8} 
> ---

Could you check in the ‘strace’ output whether PAM modules build with
another libc are being loaded?

Thanks for your report!

Ludo’.

bug#20067: [PATCH] system: grub: Introduce foreign-menu-entry.

[Ludovic Courtès]

Hi!

Tomáš Čech  skribis:

> * gnu/system/grub(foreign-menu-entry): New record type.
>
> menu-entry type is suitable for kernel and initrd from GuixSD as it is looking
> for menu-entry-linux/bzImage for kernel in every case which makes pasing any
> other form impossible.

AIUI, this is a followup to , and it’s
admittedly a shame that this isn’t fixed!

I still think that the approach proposed at
 is more
appropriate; ‘menu-entry’ would always work, no duplication would be
necessary.

As a stop-gap measure, I would prefer to (1) allow:

  (menu-entry
;; …
(linux #~(string-append #$kernel "/bzImage")))

(2) remove the “/bzImage” assumption and use the above idiom everywhere
in the current code, and (3) and have a hack along these lines to
correctly interpret (string-append …) in the ‘parameters’ file:

diff --git a/gnu/system.scm b/gnu/system.scm
index d6bf6c4..467d907 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -766,7 +766,11 @@ this file is the reconstruction of GRUB menu entries for old configurations."
  (boot-parameters
   (label label)
   (root-device root)
-  (kernel linux)
+  (kernel (match linux
+(('string-append (? string? strings) ...)
+ (string-concatenate strings))
+(_
+ linux)))
   (kernel-arguments
(match (assq 'kernel-arguments rest)
  ((_ args) args)

Thoughts?

Thanks,
Ludo’.

bug#24141: RAID reconfigure ERROR: Wrong type (expecting string): ("/dev/sdb1" "/dev/sdc1")

[myglc2]

This is a followup to bug#24135. 

Note: This may duplicate, Gmane swallowed my reply yesterday.

With bug#24135 commits in place the system reconfigure completes w/
'Installation finished. No error reported.'  _but_ shows an embedded
error ...

ERROR: Wrong type (expecting string): ("/dev/sdb1" "/dev/sdc1")

... and the system does not boot.

This is really 2 bugs

1) a problem w/the RAID mechanism and/or my config

2) reconfigure should not complete when shepherd produces errors

version info:

guix (GNU Guix) 0.11.0
root@g1 ~#   File: '/root/.config/guix/latest' -> '/home/g1/src/guix'
root@g1 ~# v0.10.0-2118-g1061862
root@g1 ~# 1061862 mapped-devices: raid-device-mapping: Avoid non-top-level 
'use-modules'.
root@g1 ~# root@g1 ~# 

reconfigure:

root@g1 ~# guix system reconfigure system40.scm
/gnu/store/nn051a04gas6x3g6xhbi8x0ca38akbzk-system
/gnu/store/dsq79n5a8p21ca7zc38yzxzi9hk0mhzp-grub.cfg
/gnu/store/zgm8s5z5y9dh0g36jqxh5i30js93irk5-grub-2.02beta3
activating system...
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/3vbg3i84k9z57kj5xwz91h08b59mh9yb-etc...
usermod: no changes
usermod: no changes
usermod: no changes
making '/gnu/store/nn051a04gas6x3g6xhbi8x0ca38akbzk-system' the current 
system...
guix system: unloading service 'device-mapping-/dev/md0'...
shepherd: Removing service 'device-mapping-/dev/md0'...
shepherd: Done.
guix system: unloading service 'file-system-/mnt/md0'...
shepherd: Removing service 'file-system-/mnt/md0'...
shepherd: Done.
guix system: loading new services: device-mapping-/dev/md0 
file-system-/mnt/md0...
shepherd: Evaluating user expression (register-services (primitive-load 
"/gn...") #).
guix system: error: exception caught while executing 'start' on service 
'device-mapping-/dev/md0':
ERROR: Wrong type (expecting string): ("/dev/sdb1" "/dev/sdc1")
Installing for i386-pc platform.
Installation finished. No error reported.

config and shepherd log attached.

TIA - George



shepherd40.log
Description: Binary data


system40.scm
Description: Binary data

bug#24140: Substitute hash mismatches not properly reported

[Ludovic Courtès]

Hello,

When using ‘guix package’, upon a substitute hash mismatch, all we see
is something like this:

--8<---cut here---start->8---
Found valid signature for 
/gnu/store/cpw9yca1mcqhqfq450dr3rz2jzr95l69-glib-2.48.0
>From 
>https://mirror.hydra.gnu.org/nar/cpw9yca1mcqhqfq450dr3rz2jzr95l69-glib-2.48.0
Downloading cpw9yc...-glib-2.48.0 (13.5MiB installed)...
 glib-2.48.0
744KiB/s 00:04 | 2.9MiB transferred
killing process 11821
guix system: error: build failed: some substitutes for the outputs of 
derivation `/gnu/store/lkvlm17z8qm1v6r4n5ja5vcmsp7d860i-graphviz-2.38.0.drv' 
failed (usually happens due to networking issues); try `--fallback' to build 
derivation from source 
--8<---cut here---end--->8---

The error message from build.cc:

--8<---cut here---start->8---
  if (expectedHash != actualHash)
  throw SubstError(format("hash mismatch in downloaded path `%1%': 
expected %2%, got %3%")
  % storePath % printHash(expectedHash) % printHash(actualHash));
--8<---cut here---end--->8---

… is only visible when we set-build-options #:print-build-trace? #t
(like ‘guix build’ does, but ‘guix package’ and others do not.)

The message should always be displayed, regardless of
#:print-build-trace?.

Ludo’.

bug#24139: gdbm is not bit-reproducible

[Ludovic Courtès]

Looks like an embedded timestamp:

--8<---cut here---start->8---
$ diff -ru --no-dereference 
/gnu/store/8pskv4xpdjg1grx3c2an3g5fqj8pcrgh-gdbm-1.12{,-check}
Binary files 
/gnu/store/8pskv4xpdjg1grx3c2an3g5fqj8pcrgh-gdbm-1.12/lib/libgdbm.a and 
/gnu/store/8pskv4xpdjg1grx3c2an3g5fqj8pcrgh-gdbm-1.12-check/lib/libgdbm.a differ
Binary files 
/gnu/store/8pskv4xpdjg1grx3c2an3g5fqj8pcrgh-gdbm-1.12/lib/libgdbm.so.4.0.0 and 
/gnu/store/8pskv4xpdjg1grx3c2an3g5fqj8pcrgh-gdbm-1.12-check/lib/libgdbm.so.4.0.0
 differ
$ git describe
v0.11.0-2-g8aceca5
$ diffoscope /gnu/store/8pskv4xpdjg1grx3c2an3g5fqj8pcrgh-gdbm-1.12{,-check}/lib
--- /gnu/store/8pskv4xpdjg1grx3c2an3g5fqj8pcrgh-gdbm-1.12/lib
+++ /gnu/store/8pskv4xpdjg1grx3c2an3g5fqj8pcrgh-gdbm-1.12-check/lib

[...]

├── libgdbm.a
│┄ xxd not available in path. Falling back to Python hexlify.

│┄ No differences found inside, yet data differs
│ @@ -2892,15 +2892,15 @@
│  2020302020202020202020202020302020202020302020202020363434202020
│  202031373834202020202020600a7f454c46020101000100
│  3e0001003803
│  40004f000c008b163917b801007f2d7c238b4e04394f
│  047f237c198b4e08394f087f190f9cc00fb6c0f7d8c30f1f8400b8ff
│  ff0f1f00f3c301000c00
│  4744424d2076657273696f6e20312e31322e2031362f30352f32
│ -30313620286275696c74204a756e20313320323031362032313a32343a323729
│ +30313620286275696c742041756720203320323031362030393a30363a353729
│  4743433a2028474e552920342e392e331400017a
│  5200017810011b0c0708900114001c003a00
│  002e73796d746162002e737472746162002e7368737472746162
│  002e74657874002e72656c612e64617461002e627373002e746578742e756e6c
│  696b656c79002e726f64617461002e726f646174612e737472312e38002e636f
│  6d6d656e74002e6e6f74652e474e552d737461636b002e72656c612e65685f66
│  72616d65

[...]

├── libgdbm.so.4.0.0
│   ├── readelf --wide --hex-dump=.rodata {}
│   │ @@ -98,10 +98,10 @@
│   │0x8c30 7778797a 30313233 34353637 38392b2f wxyz0123456789+/
│   │0x8c40 00636f75 6c646e27 7420696e 69742063 .couldn't init c
│   │0x8c50 61636865 006d616c 6c6f6320 6661696c ache.malloc fail
│   │0x8c60 65640067 64626d20 66617461 6c3a2025 ed.gdbm fatal: %
│   │0x8c70 730a 0100 0c00  s...
│   │0x8c80 4744424d 20766572 73696f6e 20312e31 GDBM version 1.1
│   │0x8c90 322e2031 362f3035 2f323031 36202862 2. 16/05/2016 (b
│   │ -  0x8ca0 75696c74 204a756e 20313320 32303136 uilt Jun 13 2016
│   │ -  0x8cb0 2032313a 32343a32 3729   21:24:27)..
│   │ +  0x8ca0 75696c74 20417567 20203320 32303136 uilt Aug  3 2016
│   │ +  0x8cb0 2030393a 30363a35 3729   09:06:57)..
--8<---cut here---end--->8---

Ludo’.

bug#24138: SIGSEGV of useradd (from shadow package)

[Tomáš Čech]

It seems to be easy to crash useradd (from shadow package).

# ls -l $(which useradd)
lrwxrwxrwx 4 root guixbuild 69 Jan  1  1970 /root/.guix-profile/sbin/useradd -> 
/gnu/store/ylnc73apl1irl0s613rxjl445x2zx8a5-shadow-4.2.1/sbin/useradd


# useradd test
Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen])

(139) # gdb $(which useradd) core
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /root/.guix-profile/sbin/useradd...(no debugging symbols 
found)...done.
[New LWP 1603]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `useradd test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f457ee6503c in call_init.part () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
(gdb) bt
#0  0x7f457ee6503c in call_init.part () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#1  0x7f457ee65205 in _dl_init () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#2  0x7f457ee696a0 in dl_open_worker () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#3  0x7f457ee64f34 in _dl_catch_error () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#4  0x7f457ee68d33 in _dl_open () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#5  0x7f457e841fb9 in dlopen_doit () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2
#6  0x7f457ee64f34 in _dl_catch_error () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#7  0x7f457e842589 in _dlerror_run () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2
#8  0x7f457e842051 in dlopen@@GLIBC_2.2.5 () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2
#9  0x7f457ea49e8d in _pam_load_module () from 
/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0
#10 0x7f457ea4a4f9 in _pam_add_handler () from 
/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0
#11 0x7f457ea4ad90 in _pam_parse_conf_file () from 
/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0
#12 0x7f457ea4b395 in _pam_init_handlers () from 
/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0
#13 0x7f457ea4cae1 in pam_start () from 
/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0
#14 0x00403351 in main ()


Interesting information about module causing it would be in stackframe
#9 but there are no debugging information available. Adding debug
`output' to linux-pam would diverge me from GuixSD.

from strace:

read(3, "account required pam_deny.so \nau"..., 4096) = 223
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_deny.so",
 O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\6\0\0\0\0\0\0"..., 
832) = 832
fstat(5, {st_mode=S_IFREG|0555, st_size=6728, ...}) = 0
mmap(NULL, 2100200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 
0x7fb8b447c000
mprotect(0x7fb8b447d000, 2093056, PROT_NONE) = 0
mmap(0x7fb8b467c000, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0) = 0x7fb8b467c000
close(5)= 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fb8b3d1bda8} ---
+++ killed by SIGSEGV (core dumped) +++

# cat /etc/pam.d/useradd
account required pam_unix.so
auth sufficient pam_rootok.so
password required pam_unix.so
session required 
/gnu/store/4mmn5y6syzv7wwz1y6bl1ab4g0yvkdq1-elogind-219.14/lib/security/pam_elogind.so
session required pam_unix.so

# cat /etc/pam.d/other
account required pam_deny.so
auth required pam_deny.so
password required pam_deny.so
session required 
/gnu/store/4mmn5y6syzv7wwz1y6bl1ab4g0yvkdq1-elogind-219.14/lib/security/pam_elogind.so
session required pam_deny.so


signature.asc
Description: Digital signature