Hi.
On Tue, 26 Apr 2016 20:14:38 +0200
Michael Luecke <m...@mluecke.eu> wrote:
> Hi,
>
> I've done your commands:
>
> On 04/26/2016 08:04 PM, Reco wrote:
> > unshare -m /bin/bash
> > mount -o bind / /mnt
> > mount -o bind /proc /mnt/proc
> > mount -o bind /dev /mnt/dev
> > chroot /mnt
> Without failure until here.
Just as planned :)
> > strace groupadd -g 1234 test
> The known failure again:
> rename("/etc/group+", "/etc/group") = -1 EBUSY (Device or resource busy)
>
> > exit
> > exit
>
> Thank you for your patient help. I attached the complete strace output.
Looks more-or-less the same as previous attempt. Moreover,
open("/etc/group+", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
umask(022) = 0777
fchown(5, 0, 0) = 0
fchmod(5, 0644) = 0
fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
...
lstat("/etc/group", {st_mode=S_IFREG|0644, st_size=824, ...}) = 0
rename("/etc/group+", "/etc/group") = -1 EBUSY
lstat shows that both /etc/group and /etc/group+ are regular files.
For the sake of the purity of the experiment, it would be nice to reboot
the system with "init=/bin/sh" added to kernel commandline (to exclude
systemd interference), but I foresee that the result would be the same.
So, to sum it up. Your current kernel + root filesystem combo prevents
you to overwrite /etc/group (and I suspect any existing file) with
another file by means of conventional rename(2) syscall, which returns
anomalous return code.
My gut feeling tells me that one should blame filesystem (btrfs)
implementation in cases such as this.
This behavior justifies a bug report with severity 'serious' against
'linux-image' package as I don't see any easy way to fix this short of
kernel patch or replacing the filesystem with something more
conventional (ext4 comes to mind).
Reco
