http://bugzilla.suse.com/show_bug.cgi?id=1143125 http://bugzilla.suse.com/show_bug.cgi?id=1143125#c13 Martin Liška changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.liska@suse.com Flags|needinfo?(mliska@suse.cz) | --- Comment #13 from Martin Liška --- (In reply to Franck Bui from comment #12)

Martin, I've been told that you might help to figure out why in this specific case setfont(8) fails to execute gzip.

I appreciate you consider me a person who can help you.

Sum-up: setfont(8) is spawned by a udev worker which is run from udev service which has MemoryDenyWriteExecute=yes. Basically this security option prevents services to execute data, please see man systemd.exec(5) for a full description of this option.

It appears that this option has a negative side effect when setfont(8) tries to run "gzip -d ..." but I don't see why especially since this issue is only happening here and I couldn't reproduce it.

I'm not much familiar with the systemd, but reading the documentation of the option: ``` ... Note that this option is incompatible with programs and libraries that generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code "trampoline" feature of various C compilers. ... ``` I would suspect executable stacks that can occur for e.g. nested functions in C, but it's not the case of gzip: $ execstack /usr/bin/gzip - /usr/bin/gzip Or one can look at all sections of the binary and there are no X+W: $ readelf -S -W /usr/bin/gzip There are 30 section headers, starting at offset 0x13780: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .interp PROGBITS 00000000000002a8 0002a8 00001c 00 A 0 0 1 [ 2] .note.gnu.build-id NOTE 00000000000002c4 0002c4 000024 00 A 0 0 4 [ 3] .note.ABI-tag NOTE 00000000000002e8 0002e8 000020 00 A 0 0 4 [ 4] .hash HASH 0000000000000308 000308 000260 04 A 6 0 8 [ 5] .gnu.hash GNU_HASH 0000000000000568 000568 00003c 00 A 6 0 8 [ 6] .dynsym DYNSYM 00000000000005a8 0005a8 0007c8 18 A 7 1 8 [ 7] .dynstr STRTAB 0000000000000d70 000d70 00032f 00 A 0 0 1 [ 8] .gnu.version VERSYM 00000000000010a0 0010a0 0000a6 02 A 6 0 2 [ 9] .gnu.version_r VERNEED 0000000000001148 001148 000080 00 A 7 1 8 [10] .rela.dyn RELA 00000000000011c8 0011c8 000960 18 A 6 0 8 [11] .rela.plt RELA 0000000000001b28 001b28 0006c0 18 AI 6 25 8 [12] .init PROGBITS 0000000000003000 003000 000017 00 AX 0 0 4 [13] .plt PROGBITS 0000000000003020 003020 000490 10 AX 0 0 16 [14] .plt.got PROGBITS 00000000000034b0 0034b0 000008 08 AX 0 0 8 [15] .text PROGBITS 00000000000034c0 0034c0 00b221 00 AX 0 0 16 [16] .fini PROGBITS 000000000000e6e4 00e6e4 000009 00 AX 0 0 4 [17] .rodata PROGBITS 000000000000f000 00f000 0020c8 00 A 0 0 32 [18] .eh_frame_hdr PROGBITS 00000000000110c8 0110c8 000314 00 A 0 0 4 [19] .eh_frame PROGBITS 00000000000113e0 0113e0 001218 00 A 0 0 8 [20] .init_array INIT_ARRAY 00000000000138f0 0128f0 000008 08 WA 0 0 8 [21] .fini_array FINI_ARRAY 00000000000138f8 0128f8 000008 08 WA 0 0 8 [22] .data.rel.ro PROGBITS 0000000000013900 012900 0004e0 00 WA 0 0 32 [23] .dynamic DYNAMIC 0000000000013de0 012de0 0001f0 10 WA 7 0 8 [24] .got PROGBITS 0000000000013fd0 012fd0 000028 08 WA 0 0 8 [25] .got.plt PROGBITS 0000000000014000 013000 000258 08 WA 0 0 8 [26] .data PROGBITS 0000000000014260 013260 0003f0 00 WA 0 0 32 [27] .bss NOBITS 0000000000014660 013650 051000 00 WA 0 0 32 [28] .gnu_debuglink PROGBITS 0000000000000000 013650 000020 00 0 0 4 [29] .shstrtab STRTAB 0000000000000000 013670 00010a 00 0 0 1 Similarly for library of those the binary depends: $ ldd /usr/bin/gzip linux-vdso.so.1 (0x00007ffe39136000) libc.so.6 => /lib64/libc.so.6 (0x00007fc9ed3b0000) /lib64/ld-linux-x86-64.so.2 (0x00007fc9ed619000)

Do you have an idea how this could be debugged further so we can understand why MemoryDenyWriteExecute=yes has a bad effect in this specific case ?

I would attach to the gzip with gdb and catch ta signal. Hope it will help.

Thanks.

-- You are receiving this mail because: You are on the CC list for the bug.