Re: [REVIEW][PATCH 3/3] vfs: Fix a regression in mounting proc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Oleg Nesterov (oleg@xxxxxxxxxx):
> To all: sorry for noise, I can't comment this patch.
> 
> 
> But Eric, could you please help me to understand? I am totally confused.
> 
> So, afaics, initially (even after MS_KERNMOUNT) fs_fully_visible("proc")
> should return false.
> 
> After the normal "mout -t proc none /proc/" it becomes true.
> 
> And it is still true after, say, "mount -t ramfs none /proc/sys" because
> "ls -ld /proc/sys" shows ->i_nlink == 1.
> 
> However, say, "mount -t ramfs none /proc/tty/" should make
> fs_fully_visible() == F, because in this case ->i_nlink == 4.
> 
> Correct?
> 
> If yes, could you explain what this "!CAP_SYS_ADMIN && !fs_fully_visible"
> check actually tries to prevent and why?

The idea is that some admin on a host where /a/b/c/d exists, c/d should
be hidden, so overmounts a tmpfs onto /a/b/c.  In that case, an unpriv
user could clone(CLONE_NEWUSER), then clone(CLONE_NEWNS), then umount
/a/b/c and see /a/b/c/d.  This patch was to try and prevent that.

I argue that it is easy enough for the admin to make /a/b/c permissions
such that it can't be crossed by an unprivileged user, but that does
require an action on the part of admins who used this (imo misguided)
approach.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux