If flags are set for example to "--me-" # getfattr -d /usr/games/bin/xonotic-glx getfattr: Removing leading '/' from absolute path names # file: usr/games/bin/xonotic-glx user.pax.flags="--me-" kernel seems to ignore these flags It's caused by not handling '-' in them in fs/binfmt_elf.c static unsigned long pax_parse_xattr_pax(struct file * const file) { ..... for (i = 0; i < xattr_size; i++) switch (xattr_value[i]) { default: return ~0UL; <-- it quits here After adding simple case '-': /* ignore not set flag */ break; everything works again. Reproducible: Always
Created attachment 331828 [details, diff] Patch with change proposed in bug report
Okay this is a misunderstanding (probably on my part) on how the paxflags are set when they are "blank". @pipacs, suppose we have something like pax flags = "--me-", where the field order is something like PSMER, what exactly should user.pax.flags look like?
(In reply to comment #2) > Okay this is a misunderstanding (probably on my part) on how the paxflags > are set when they are "blank". > > @pipacs, suppose we have something like pax flags = "--me-", where the > field order is something like PSMER, what exactly should user.pax.flags look > like? I read the code. I see how the implementation works. There is a variable xattr_size. @pipacs: Can we consider a "blank" char like '-' so that the xattr field is always 5 chars long and it can nicely be formated when printed out? Adding adding a case '-': continue; seem innocent enough.
Could paxctl-ng set real text value "me" ( user.pax.flags="me" ), and formatted display "--me-" ?
(In reply to comment #4) > Could paxctl-ng set real text value "me" ( user.pax.flags="me" ), and > formatted display "--me-" ? paxctl-ng is easy to fix. i'm thinking more of setfattr in conjunction with script.s
the pax flags as stored have never been the same as the flags shown to a human user (or parser script) and i don't want to tie one to the other in the future either. for user.pax.flags this means that you are not supposed to set it to the output your parsed out from paxctl (the PT_PAX_FLAGS value has nothing to do with the paxctl output either, one's binary, the other's ascii text), you must set it to actually meaningful flags that you want enabled/disabled on the given binary (not unlike you already have to do with paxctl ;). a '-' does not mean anything (at least not now, i can't predict the future of course ;) so it will not be accepted by the kernel. this is by design and this bug is invalid, as far as the kernel side is concerned. for the '--me-' example, user.pax.flags should be set to 'me' or 'em, the ordering doesn't matter (much like it never mattered to paxctl either). so if there's a bug here, it's the inclusion of '-' in the user.pax.flags value.
(In reply to comment #6) > the pax flags as stored have never been the same as the flags shown to a > human user (or parser script) and i don't want to tie one to the other in > the future either. for user.pax.flags this means that you are not supposed > to set it to the output your parsed out from paxctl (the PT_PAX_FLAGS value > has nothing to do with the paxctl output either, one's binary, the other's > ascii text), you must set it to actually meaningful flags that you want > enabled/disabled on the given binary (not unlike you already have to do with > paxctl ;). a '-' does not mean anything (at least not now, i can't predict > the future of course ;) so it will not be accepted by the kernel. this is by > design and this bug is invalid, as far as the kernel side is concerned. for > the '--me-' example, user.pax.flags should be set to 'me' or 'em, the > ordering doesn't matter (much like it never mattered to paxctl either). so > if there's a bug here, it's the inclusion of '-' in the user.pax.flags value. Okay we'll code accordingly in our scripts.
(In reply to comment #7) > (In reply to comment #6) > > the pax flags as stored have never been the same as the flags shown to a > > human user (or parser script) and i don't want to tie one to the other in > > the future either. for user.pax.flags this means that you are not supposed > > to set it to the output your parsed out from paxctl (the PT_PAX_FLAGS value > > has nothing to do with the paxctl output either, one's binary, the other's > > ascii text), you must set it to actually meaningful flags that you want > > enabled/disabled on the given binary (not unlike you already have to do with > > paxctl ;). a '-' does not mean anything (at least not now, i can't predict > > the future of course ;) so it will not be accepted by the kernel. this is by > > design and this bug is invalid, as far as the kernel side is concerned. for > > the '--me-' example, user.pax.flags should be set to 'me' or 'em, the > > ordering doesn't matter (much like it never mattered to paxctl either). so > > if there's a bug here, it's the inclusion of '-' in the user.pax.flags value. > > Okay we'll code accordingly in our scripts. I just committed =dev-python/pypax-0.7.0 and =sys-apps/elfix-0.7.0 to the tree. They fix this bug and should work with the new eclass correctly. Please test.
Testing with valgrind * XT PaX marking -m * /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/cachegrind-amd64-linux * /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/callgrind-amd64-linux * /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/drd-amd64-linux * /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/exp-bbv-amd64-linux * /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/exp-dhat-amd64-linux * /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/exp-sgcheck-amd64-linux * /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/helgrind-amd64-linux * /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/lackey-amd64-linux * /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/massif-amd64-linux * /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/memcheck-amd64-linux * /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/none-amd64-linux # paxctl-ng -v /usr/lib64/valgrind/cachegrind-amd64-linux /usr/lib64/valgrind/cachegrind-amd64-linux: XT_PAX: -em-- # getfattr -d /usr/lib64/valgrind/cachegrind-amd64-linux getfattr: Removing leading '/' from absolute path names # file: usr/lib64/valgrind/cachegrind-amd64-linux user.pax.flags="em" # paxctl-ng -v /usr/lib64/valgrind/callgrind-amd64-linux /usr/lib64/valgrind/callgrind-amd64-linux: XT_PAX: -em-- # getfattr -d /usr/lib64/valgrind/callgrind-amd64-linux getfattr: Removing leading '/' from absolute path names # file: usr/lib64/valgrind/callgrind-amd64-linux user.pax.flags="em" Looks like this problem with paxctl-ng is fixed.
