On Sun, Oct 27, 2019 at 09:24:52AM +0200, Amir Goldstein wrote: > Well, it's not that simple (TM). > If you are considering unprivileged overlay mounts, then this should be > ns_capable() check, even though open_by_handle_at(2) does not > currently allow userspace nfsd to decode file handles. > > Unlike open_by_handle_at(2), overlayfs (currently) never exposes file > data via decoded origin fh. AFAIK, it only exposes the origin st_ino > st_dev and some nlink related accounting. > > I have been trying to understand from code if nfsd exports are allowed > from non privileged containers and couldn't figure it out (?). > If non privileged container is allowed to export nosubtreecheck export > then non privileged container root can already decode file handles... I don't see any special checks in nfsctl_transaction_write() or write_threads(). I guess it's just depending on the (0600) file permissions. I'm vague on how file permissions work in containers. The issue with filehandles is that they allow you to bypass directory lookup permissions. Keeping a file private by denying permission to look it up doesn't sound like a good idea to me, honestly, but it does work on local posix filesystems, so we don't want to break that. Filehandles are generally pretty easy to guess, and can't be revoked, so we're more worried about using them (with open_by_handle_at()) than reading them (with name_to_handle_at()), but we try to prevent the latter as well. --b.
