Comment # 13
on bug 1143125
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.