On Wed, 08 Jan 2025, Christopher Bii wrote: > Hello, > > You are correct, it would be a configuration error. But the issue is > that when a rootdir is set, export entries are assumed to be relative to > the rootdir path, but this isn't the case. The above statement directly contradicts the documentation which says that all exports *are* relative to rootdir (more accurately: the path is prefixed with the rootdir). So if true it is clearly a bug that needs to be fixed, and would have nothing to do with symlinks. But I don't think it is true. What you have been saying is that if the export point - which is at $rootdir/$exportpath - is a symlink, then that symlink is resolved without reference to the rootdir. This is true but I don't see why it is a problem. When you create /etc/exports (or run exportfs) you should only identify directories, never symlinks. And all ancestors of these directories should only be modifiable by privileged processes. What is your use case for exporting a symlink, or exporting anything in a directory that is not restricted to privileged users? Thanks, NeilBrown > So my rootdir can have a > restrictive set of permissions, but the export entry path relative to > the system* rootdir may have an entirely different set of permissions. > Or even with restrictive permissions it could be accidentally or > maliciously symlinked. > > Christopher Bii > > NeilBrown wrote: > > On Sat, 07 Dec 2024, Christopher Bii wrote: > >> Hello, > >> > >> It is hinted in the configuration files that an attacker could gain access > >> to arbitrary folders by guessing symlink paths that match exported dirs, > >> but this is not the case. They can get access to the root export with > >> certainty by simply symlinking to "../../../../../../../", which will > >> always return "/". > >> > >> This is due to realpath() being called in the main thread which isn't > >> chrooted, concatenating the result with the export root to create the > >> export entry's final absolute path which the kernel then exports. > >> > >> PS: I already sent this patch to the mailing list about the same subject > >> but it was poorly formatted. Changes were merged into a single commit. I > >> have broken it up into smaller commits and made the patch into a single > >> thread. Pardon the mistake, first contribution. > > > > I'm still not convinced there is a vulnerability here, but I might have > > missed part of the conversation... > > > > Could you please spell out in detail the threat scenario that we are > > trying to defend against? > > > > From my perspective: if you export a path that a non-privileged user can > > modify, then that is a configuration error. We should not try to make > > it "safe". We could possibly try to detect that situation and fail the > > export when it happens. > > > > Why is that perspective not correct? If this has already been > > discussed, please point me to the relevant email. > > > > Thanks, > > NeilBrown > >
