| Summary: | sys-apps/install-xattr - install-xattr incorrectly processes -Z flag | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Raimonds Cicans <ray> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | CONFIRMED --- | ||
| Severity: | major | CC: | base-system, d |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=699548 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 699552 | ||
| Attachments: | Workaround - works for me | ||
Good catch. I'll commit, cut a new release and test over the weekend. (In reply to Raimonds Cicans from comment #0) > This is caused by one of calls to glibc’s function “getopt_long”, which > mangle program’s “argv” variable. > > I’m not competent to say which one is root cause: bug in glibc or wrong > parameters sent to function “getopt_long”. > Your patch doesn't fix the issue for me. The root problem is getopt_long() mangling argv. I need to make a copy of argv for parsing to avoid this :( Hmmm.... Yes. My patch is wrong. It is expected behaviour from getopt* family of functions. Excerpt from getopt man page: > By default, getopt() permutes the contents of argv as it scans, so that eventually all the nonoptions are at the end. But is copying of argv really necessary? According to getopt man page: > If the first character of optstring is '-', then each nonoption argv-element is handled as if it were the argument of an option with character code 1. > (This is used by programs that were written to expect options and other argv-elements in any order and that care about the ordering of the two.) My simple test showed that adding '-' to begining of optstring will result in preserved argv content. But i'm not sure how it affect rest of code. (In reply to Raimonds Cicans from comment #3) > Hmmm.... > > Yes. My patch is wrong. > Please test install-xattr-0.8 which I added to the tree. profile: default/linux/amd64/17.1/desktop/plasma/systemd test case & app-emulation/libpod: Ok (as before,no regression) profile: default/linux/amd64/17.1/no-multilib/hardened/selinux test case: now Ok app-emulation/libpod: still fails, but little more further (looks one more bug, not related to this bug) *** Bug 690836 has been marked as a duplicate of this bug. *** Moving bug 699548 to See Also as there is no real dependency here. |
Created attachment 595242 [details, diff] Workaround - works for me “install-xattr” allow “-Z” flag to have option(s) (unlike “install” from package “sys-apps/coreutils” which it tries to mimic) which leads to strange behaviour in some cases – in subsequent call to “install” some parameters switch places which may lead to error. Test case (works on any Linux profile, not only selinux): strace -f install-xattr -Z -m 755 -d /tmp/213 2>&1 | grep execve Result: execve("/usr/bin/install-xattr", ["install-xattr", "-Z", "-m", "755", "-d", "/tmp/213"], 0x7ffe5034fdb0 /* 51 vars */) = 0 [pid 578966] execve("/usr/bin/install", ["/usr/bin/install", "-Z", "-m", "-d", "755", "/tmp/213"], 0x7ffdeca8aac0 /* 51 vars */) = 0 Parameters “755” and “-d” switched places!!! This is caused by one of calls to glibc’s function “getopt_long”, which mangle program’s “argv” variable. I’m not competent to say which one is root cause: bug in glibc or wrong parameters sent to function “getopt_long”. After fixing, it may be good idea to review all build bugs on selinux profiles which fail with strange errors in install stage…