[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Non-evasive patch for SELinux handling suitable for a freeze exception?



Cyril Brulebois wrote on 2012-07-22 04:53:15 +0200:
> (For lazy people following at home, it's about debian/init) The patched
> init script would have:
> | set -e
> | …
> | [ -x /sbin/restorecon ] && /sbin/restorecon $SCREENDIR

Thus the patched init script would work just fine because the restorecon 
list compound-list is not the last command in the init script.

> Meaning you never get to do the clean-up and the chmod dance if the
> policycoreutils package isn't installed.

This seems to be a persistent misunderstanding. As a matter of fact, the 
-e option does not have an effect on left hand operands of AND (&&) and 
OR (||) lists just like it does not have an effect on the command used 
to control if, elif, while and until compound commands.

The root of this misunderstanding is probably the fact that the default 
exit status of a shell is the exit status of the last command and that 
the exit status of an if compound command is 0 if none of the compound 
lists was executed but the exit status of an AND list is the exit status 
of the last command in the list which was executed.

Therefore, the following script will print exit statuses 1 and 0 in that 
order (provided that the file /nonexisting does not exist):
| set -e
| [ -x /nonexisting ] && /nonexisting
| echo $?
| if [ -x /nonexisting ]; then
|     /nonexisting
| fi
| echo $?

PS.

To be precise, the list compound-list
     [ -x /sbin/restorecon ] && /sbin/restorecon $SCREENDIR

works fine in all practical situations but not in all imaginable 
situations. If the [ command is not a builtin command (unlike in bash, 
dash and busybox) and the policycoreutils package is installed but the 
external [ command terminates abnormally (due to lack of resources or 
due to a signal, for instance), the abnormal termination remains 
unnoticed, That is, however, a non-issue for normal systems because the 
[ command is a practically always a shell builtin.


Reply to: