On Mon, Mar 2, 2015 at 11:59 PM, Alexander Larsson <[email protected]> wrote:
> On mån, 2015-03-02 at 11:09 -0600, Eric W. Biederman wrote:
>> Alexander Larsson <[email protected]> writes:
>> >
>> > I am able to do a bind mount of the system one, *if* i pass in MS_REC
>> > (which is not necessarily what i want), but I then later fail when
>> > trying to remount it read-only.
>>
>> MS_REC should be only required if there is something mounted on top of
>> one of the files in sysfs.  It sounds like there is, and exposing that
>> file would be a permission issue.
>>
>> Remount read-only comes in two flavors.  A bind mount remount read-only
>> which you should be able to perform as non-root and a remount the
>> filesystem read-only for everyone.  I suspect you simply didn't specify
>> MS_BIND | MS_RDONLY when attempting to remount sysfs.
>
> I've attached a simple test app that tries to bind mount /sys and
> remount it readonly. It fails with EPERM.
>
> The mounts i have over /sys are:
>
> 15 57 0:15 / /sys rw,nosuid,nodev,noexec,relatime shared:6 - sysfs sysfs 
> rw,seclabel
> 18 15 0:16 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:7 - 
> securityfs securityfs rw
> 22 15 0:19 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:8 - tmpfs tmpfs 
> ro,seclabel,mode=755
> 23 22 0:20 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:9 
> - cgroup cgroup 
> rw,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
> 24 15 0:21 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:19 - 
> pstore pstore rw
> 25 22 0:22 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:10 
> - cgroup cgroup rw,cpuset
> 26 22 0:23 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime 
> shared:11 - cgroup cgroup rw,cpu,cpuacct
> 27 22 0:24 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:12 
> - cgroup cgroup rw,memory
> 28 22 0:25 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:13 
> - cgroup cgroup rw,devices
> 29 22 0:26 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:14 
> - cgroup cgroup rw,freezer
> 30 22 0:27 / /sys/fs/cgroup/net_cls,net_prio rw,nosuid,nodev,noexec,relatime 
> shared:15 - cgroup cgroup rw,net_cls,net_prio
> 31 22 0:28 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:16 - 
> cgroup cgroup rw,blkio
> 32 22 0:29 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime 
> shared:17 - cgroup cgroup rw,perf_event
> 33 22 0:30 / /sys/fs/cgroup/hugetlb rw,nosuid,nodev,noexec,relatime shared:18 
> - cgroup cgroup rw,hugetlb
> 54 15 0:31 / /sys/kernel/config rw,relatime shared:20 - configfs configfs rw
> 34 15 0:14 / /sys/fs/selinux rw,relatime shared:21 - selinuxfs selinuxfs rw
> 38 15 0:6 / /sys/kernel/debug rw,relatime shared:26 - debugfs debugfs rw
> 202 15 0:48 / /sys/fs/fuse/connections rw,relatime shared:147 - fusectl 
> fusectl rw
>
> Also, I'd like to make all the recursively bound subtrees readonly. Is
> there a better way to do this than enumerating all mounts and remounting
> all that are under /sys.
>
> In fact this is a general problem i have with recursive bind mounts. If
> I want to grant access to some directory with limited access (for
> example read-only or nosuid) then I have to use a recursive bind mount,
> but the remount is not recursive, and furthermore, it does not apply to
> later mounts that get propagated into my namespace.
>

Oh, yuck.

We should finally just make readonly bind mounts work in the first
place.  You can partially mitigate this my remounting private before
you remount ro, though.

--Andy

> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc
>        [email protected]            [email protected]
> He's a world-famous flyboy werewolf with a passion for fast cars. She's
> an enchanted junkie vampire from aristocratic European stock. They fight
> crime!



-- 
Andy Lutomirski
AMA Capital Management, LLC
_______________________________________________
gnome-os-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-os-list

Reply via email to