Hide Forgot
Created attachment 495797 [details] reproducer Description of problem: While running the kernel tests using the latest baseline RHEL5.7-Server-20110428.0.n the selinux and audit testing started to fail. Version-Release number of selected component (if applicable): coreutils-5.97-32.el5 How reproducible: Always Steps to Reproduce: 1. Install RHEL5.7-Server-20110428.0.n 2. Use attached reproducer Actual results: WORKS -> c = getopt_long(argc, argv, "r:t:u:l:c", long_options, &option_index); FAILS -> c = getopt_long(argc, argv, "+r:t:u:l:c", long_options, &option_index); Expected results: commands will not change behaviour in updates Additional info:
Here is a another example, which demonstrates the change in behavior: -- cut 1.sh -- #!/bin/bash echo "<$0> <$1> <$2> <$3> <$4>" -- cut -- runcon -u root -r sysadm_r -t unconfined_t -- ./1.sh 1 2 3 4 <./1.sh> <1> <2> <3> <4> runcon -u root -r sysadm_r -t unconfined_t ./1.sh -- 1 2 3 4 <./1.sh> <--> <1> <2> <3> If I run the same on RHEL5.6: runcon -u root -r sysadm_r -t unconfined_t ./1.sh -- 1 2 3 4 <./1.sh> <1> <2> <3> <4>
Thanks for the report. However, that this has changed in 5.7 is a bug *fix*, not a bug. The previous behavior was erroneous. Here is the bug report that prompted the change: https://bugzilla.redhat.com/show_bug.cgi?id=232652 Please adjust your test not to depend on the old, erroneous behavior. Note that the 5.6 behavior of omitting the "--" argument was wrong, just as the 5.6 behavior of reordering options (as reported in that BZ) was wrong.
There should be some backwards compatibility, so we have common way to do things for both RHEL5.6 and RHEL5.7. Consider following: runcon root:system_r:unconfined_t ps -a RHEL5.6 FAIL RHEL5.7 OK runcon root:system_r:unconfined_t -- ps -a RHEL5.6 OK RHEL5.7 FAIL
Hi Jan, How does "runcon root:system_r:unconfined_t -- ps -a" fail on RHEL5.7? What about "runcon root:system_r:unconfined_t:s0 -- ps -a"? (note the added :s0, without which I'd get a failure due to invalid context on the system where I tried it) This: runcon root:system_r:unconfined_t:s0 -- ps -a works just fine for me on RHEL 5.6, and it should work just as well using the runcon from the fixed coreutils of RHEL 5.7. The use of runcon without "--" (to protect command arguments from interpretation by the buggy runcon) is buggy and should be avoided.
Jim, I think it will show runcon: --: no such file or directory - as when you specify the full context, the (c==-1) break in option parser with no reordering will cause the -- to be used as command. Jeff,Jan, Probably some workaround could be done to make you happy - (please use https://bugzilla.redhat.com/show_bug.cgi?id=628953 for any comments anyway as this is the request for change in the fix for it) - I could probably skip an argument after we are done with type/context/whatever, if the argument is -- -> so even your -- old workaround for bug separator will work without problem. When I use something like if (!strcmp(argv[optind],"--") optind++; just after context = argv[optind++]; , everything works just fine.
Note: I think this should be used only in RHEL-5 to not break existing workaround, I don't think this is something which should be done in RHEL-6 or in upstream, as you should not use the option separator, when no option are used at all... btw. everything is just fine and you could get both versions working properly if you use the option separator BEFORE the context, when specifying full context, with no options in runcon. (e.g. runcon -- root:system_r:unconfined_t ps -a )
Jim, Here is what we see. # runcon root:system_r:unconfined_t:s0 -- ps -a execvp: No such file or directory # runcon root:system_r:unconfined_t:s0 ps -a PID TTY TIME CMD 3195 pts/0 00:00:18 yum 3226 ttyS0 00:00:00 ps Ondrej, This is not just to make us happy. There is no argument. We can modify our tests to work. I was just pointing out that a change like this results in a bad customer experience.
(In reply to comment #6) > Hi Jan, > > How does "runcon root:system_r:unconfined_t -- ps -a" > fail on RHEL5.7? runcon root:system_r:unconfined_t -- ps -a execvp: No such file or directory > > What about "runcon root:system_r:unconfined_t:s0 -- ps -a"? runcon root:system_r:unconfined_t:s0 -- ps -a execvp: No such file or directory > This: > > runcon root:system_r:unconfined_t:s0 -- ps -a > > works just fine for me on RHEL 5.6, and it should work just as well using > the runcon from the fixed coreutils of RHEL 5.7. > > The use of runcon without "--" (to protect command arguments > from interpretation by the buggy runcon) is buggy and should be avoided. So, do you actually recommend to use "--"? Then change made in bz #232652 seems pointless as its effect is that you don't need to write "--". I'm not sure what "reordering getopt arguments" mean. My impression is that '--' and '+' are a bit in conflict if you use non-opt arg (like the example I gave in comment #5). So, if you actually stick with opt args only, e.g.: runcon -u root -r system_r -t unconfined_t -l s0 -- ps -a this works also on RHEL5.7 and RHEL5.6.
As I have said, you have -- separator on WRONG PLACE ... get_opt_long manpage: The special argument `--' forces an end of option-scanning regardless of the scanning mode. root:system_r:unconfined_t:s0 is context and not an option - there is no - , -- in that string. So get_opt_long cycle just ends. Only because of reordering it was working as you expected - as this option-separator was moved before the context string. runcon -- root:system_r:unconfined_t:s0 ps -a works just fine in both versions... but as you and Jan are using the wrong place, it really makes sense to workaround your wrong workarounds in RHEL-5 (as it was buggy for long time) - as the customers may have the same issue. I'll do a respin, but I still say this is not a bug.
(In reply to comment #12) > As I have said, you have -- separator on WRONG PLACE ... After digging in background, I can see this now. However runcon manpage is not giving much clue about where you can and can't put that "--" flag.
This is nothing specific to runcon. $ info coreutils common options