Alon Zahavi: > I understand but think you may consider taking more security measures in > regards to the problem. For example, one way to overcome this issue is to > check if a copy-up-ed file is a capable file, and if it is, strip the > capabilities from it. Another mitigation is to check at the mounting time > if one of the filesystems that become an aufs branch is mounted with > "nosuid" and if so, automatically mount aufs with the "nosuid" option.
I don't agree. If aufs drops the file capability in the internal copy-up and your command exists on the lower RO branch, then "touch /your/command" will drop the file-cap as you are wanting. But if your command exists on the upper RW branch, then the internal copy-up won't happen and the command will keep its file-cap. It means the result depends upon the branch where the command exists originally. Such undeterministic behaviour is not acceptable. If you run "touch /your/command" on an ordinary filesystem, then the command won't lose its file capability regardless the nosuid mount option. This behaviour should not be changed in aufs, I believe. For your problem, adding "nosuid" to your aufs mount is the solution, I think. J. R. Okajima
