writing zero bytes in bash

[Russell Coker]

This message is intentionally sent to the fedora-devel-list and the SE Linux 
list not the fedora-selinux-list.  It is not related to Fedora specific SE 
Linux functionality, but it is related to bash (a core part of Fedora) and SE 
Linux kernel code.

To unset the fscreate or exec context you have to write zero bytes 
to /proc/self/attr/fscreate or /proc/self/attr/exec respectively.

If you want to do this in a shell script you would do something like:
echo -n "" > /proc/self/attr/fscreate

However that shell command results in bash (both the version in rawhide and 
the version in RHEL4) performing the following system calls:

open("/proc/self/attr/exec", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
fcntl64(1, F_GETFD)                     = 0
fcntl64(1, F_DUPFD, 10)                 = 10
fcntl64(1, F_GETFD)                     = 0
fcntl64(10, F_SETFD, FD_CLOEXEC)        = 0
dup2(3, 1)                              = 1
close(3)                                = 0
dup2(10, 1)                             = 1
fcntl64(10, F_GETFD)                    = 0x1 (flags FD_CLOEXEC)
close(10)                               = 0

It opens the file with O_CREAT (so if you were to do `echo -n "" > /tmp/flag` 
to create a flag file then it would work as expected), but never calls the 
write(2) system call.

To unset the fscreate or exec context you have to call write(fd, X, 0) (the 
value of X doesn't seem to matter as the kernel code doesn't dereference it).

It seems likely to me that there may be other bits of kernel code exporting an 
interface under /proc where a write of 0 bytes may have a different meaning 
to merely opening a file with write access and then closing it.

So it seems reasonable to me to consider this to be a bug in bash where it's 
optimisation of shell code results in the action requested by the user not 
being performed correctly.

It took a surprising amount of time for me to realise that bash wasn't doing 
what I expected of it and ran strace to prove it.  I expect that most 
sys-admins would take even longer to work it out (if they ever did).

I expect that the bash developers may disagree with this assessment so I would 
like some more input on the lists before I file a bug report.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page