Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
...
> Sounds more like a bug in mcstrans to me - giving back an empty string
> in place of the "xxx" so that the kernel never sees the "xxx"? Or do I
> misunderstand your description above.
You are probably right about it being an mcstrans bug.
When I turn it off (service mcstrans stop) and rerun the test,
the problem is gone: i.e., it prints all '.'s and no X's.
rm -rf d; while :; do mkdir d -Z xxx 2> /dev/null&&{t=X;rmdir d;}||t=.;
printf $t 1>&2;done
> However, I'm a little surprised by the EINVAL above as well from the
> kernel, as the selinux_setprocattr handler in the kernel is written to
> accept NULL, "\0", or "\n" as a way of clearing the attribute value
> (resetting to policy default). setfscreatecon(NULL) does the former for
> use by programs, while echo -n "" > /proc/self/attr/fscreate does the
> last one for use from scripts. I'm wondering if we are running afoul of
> some inconsistency in the proc code itself before we reach the selinux
> code. So possibly a kernel bug report would also make sense. But the
> mcstrans issue is more crucial, as we shouldn't be mapping an invalid
> context to the empty string there.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
