Hello, On Thu, 2015-08-13 at 10:20 -0500, Eric W. Biederman wrote: > Lubomir Rintel <lkundrak@xxxxx> writes: > > > Hi, > > > > 4.0.6-300.fc22.x86_64: > > [lkundrak@fedora22-1 ~]$ unshare -r --mount --net > > [root@fedora22-1 ~]# mount --make-slave /sys > > [root@fedora22-1 ~]# mount -t sysfs sysfs /sys > > [root@fedora22-1 ~]# > > > > 4.2.0-0.rc6.git0.1.fc24.x86_64: > > [lkundrak@fedora23-1 ~]$ unshare -r --mount --net > > [root@fedora23-1 ~]# mount --make-slave /sys > > [root@fedora23-1 ~]# mount -t sysfs sysfs /sys > > mount: permission denied > > [root@fedora23-1 ~]# > > > > we use this in NetworkManager test suite, to ensure the devices we > > see > > via GUdev are the same as we see via rtnetlink. > > > > I'm wondering if this is a bug or an intended change? > > There was an intentional tightening up of the permissions required to > mount sysfs to prevent people in jails from gaining access to things > they would not ordinarily have access to. The change was not > expected > to affect anyones legitimate use case. > > What are the mount flags of the previous mount of sysfs? > What is mounted on top of sysfs? > > Or in short can I see /proc/self/mounts for the failing scenario? Looks like this: sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,relatime 0 0 devtmpfs /dev devtmpfs rw,seclabel,nosuid,size=882904k,nr_inodes=220726,mode=755 0 0 securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev 0 0 devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,seclabel,nosuid,nodev,mode=755 0 0 tmpfs /sys/fs/cgroup tmpfs ro,seclabel,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 pstore /sys/fs/pstore pstore rw,seclabel,nosuid,nodev,noexec,relatime 0 0 kdbusfs /sys/fs/kdbus kdbusfs rw,nosuid,nodev,noexec,relatime 0 0 cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0 cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 configfs /sys/kernel/config configfs rw,relatime 0 0 /dev/vda3 / btrfs rw,seclabel,relatime,space_cache,subvolid=5,subvol=/ 0 0 selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=36,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0 tmpfs /tmp tmpfs rw,seclabel 0 0 mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0 debugfs /sys/kernel/debug debugfs rw,seclabel,relatime 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0 /dev/vda1 /boot ext4 rw,seclabel,relatime,data=ordered 0 0 tmpfs /run/user/42 tmpfs rw,seclabel,nosuid,nodev,relatime,size=178648k,mode=700,uid=42,gid=42 0 0 gvfsd-fuse /run/user/42/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=42,group_id=42 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 tmpfs /run/user/8086 tmpfs rw,seclabel,nosuid,nodev,relatime,size=178648k,mode=700,uid=8086,gid=8086 0 0 gvfsd-fuse /run/user/8086/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=8086,group_id=8086 0 0 > Without a little more detail I can't see if there is a possible > security > violation in your code or if this is something I can fix. > > Eric Thanks for the response Lubo -- 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
