On 3/23/21 11:18 AM, Walter Harms via GNU coreutils Bug Reports wrote: > In my case there was no security context involved. > It was a loop device mounted (that i was not aware of, > the image was already gone). > and rm -r stoped here because of "in use". > > I expected some mentioning of mount somewhere.
According to the source code [1], the directory must have had a security context set. [1] https://git.sv.gnu.org/cgit/coreutils.git/tree/src/ls.c?id=4698e284f#n4243 So if it was a mount point, then the only logical conclusion is that the top-most directory of the mounted filesystem had this security context set. Reproducer: # Create an EXT4 file system and loop-mount it. $ dd if=/dev/zero of=x.img bs=1M count=128 status=none $ mkfs.ext4 -q x.img $ mount -o loop x.img /mnt # Initially, there's no security context, hence no '.' after the permission string. $ ls -ld /mnt drwxr-xr-x 3 root root 1024 Mar 25 23:54 /mnt # Apply a security context. $ setfattr -n security.selinux -v somevalue /mnt # Now, ls(1) prints the '.' after the permission string as a hint to the security context. $ ls -ld /mnt drwxr-xr-x. 3 root root 1024 Mar 25 23:54 /mnt Have a nice day, Berny
