I've been watching this thread with some interest, and I think it's time I say something.
On Fri, 03 Sep 2021 01:28:06 +0900 hooanon...@gmail.com wrote: > 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. > Good call Junjiro-san. One of the important point for aufs is that the behaviour between aufs mount should be as similar and consistent with any other non-aufs mounts (as far as it is possible and supported by the lower branch). If the top mount (=aufs) is configured relaxedly, then aufs should behave relaxedly either. > For your problem, adding "nosuid" to your aufs mount is the solution, I > think. > Exactly. Don't rely on specifying on "nosuid" on the branches and expecting the "nosuid" to carry forward, instead, put "nosuid" in the top-level aufs mount itself. After all that's how one does it with any other mounts - one specifies the parameter that one needs, on the mount that will be seen by the users. cheers! -- James B
