I wanted to try and bring this thread back from the dead (?) as I believe the use-case is still valid and worth supporting. Some more brief comments below ... On Fri, Dec 3, 2021 at 1:34 PM Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > I am not sure. In the early version of patches I think argument was > that do not switch to mounter's creds and use caller's creds on > underlying filesystem as well. And each caller will be privileged > enough to be able to perform the operation. The basic idea is that we can now build Linux systems with enough access control granularity such that a given process can have the necessary privileges to mount a filesystem, but not necessarily access all of the data on the filesystem, while other processes, with different access rights, are allowed to read and write data on the mounted filesystem. Granted, this is a bit different from how things are usually done, but in my opinion it's a valid and interesting use case in that it allows us to remove unneeded access rights from historically very privileged system startup services/scripts: the service that runs to mount my homedir shouldn't be allowed to access my files just to mount the directory. Unfortunately, this idea falls apart when we attempt to use overlayfs due to the clever/usual way it caches the mounting processes credentials and uses that in place of the current process' credentials when accessing certain parts of the underlying filesystems. The current overlayfs implementation assumes that the mounter will always be more privileged than the processes accessing the filesystem, it would be nice if we could build a mechanism that didn't have this assumption baked into the implementation. This patchset may not have been The Answer, but surely there is something we can do to support this use-case. > Our take was that how is this model better because in current model > only mounter needs to be privileged while in this new model each > caller will have to be privileged. But Android guys seemed to be ok > with that. So has this assumption changed since early days. If callers > are privileged, then vfs_getxattr() on underlying filesystem for > overaly internal xattrs should succeed and there is no need for this > change. > > I suspect patches have evolved since then and callers are not as > privileged as we expect them to and that's why we are bypassing this > check on all overlayfs internal trusted xattrs? This definitely requires > much close scrutiny. My initial reaction is that this sounds very scary. > > In general I would think overlayfs should not bypass the check on > underlying fs. Either checks should be done in mounter's context or > caller's context (depending on override_creds=on/off). > > Thanks > Vivek -- paul-moore.com
