Bug 700843

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