On 2018-09-29, Andy Lutomirski <[email protected]> wrote: > > The most obvious change is that AT_NO_JUMPS has been split as dicussed > > in the original thread, along with a further split of AT_NO_PROCLINKS > > which means that each individual property of AT_NO_JUMPS is now a > > separate flag: > > > > * Path-based escapes from the starting-point using "/" or ".." are > > blocked by AT_BENEATH. > > Seems useful. > > > * Mountpoint crossings are blocked by AT_XDEV. > > Seems useful. > > > * /proc/$pid/fd/$fd resolution is blocked by AT_NO_PROCLINKS (more > > correctly it actually blocks any user of nd_jump_link() because it > > allows out-of-VFS path resolution manipulation). > > > > So how do I disable following symlinks? ISTM the most natural way > would be to have AT_NO_SYMLINKS, and to have that flag disable proc > links.
So, this patchset has both AT_NO_SYMLINKS and AT_NO_PROCLINKS.
* AT_NO_SYMLINKS blocks *all* symlinks (which is something Linus requested
in the original thread[2] -- apparently this is something that would
be useful to git even if wouldn't violate AT_BENEATH). This implies
AT_NO_PROCLINKS.
* AT_NO_PROCLINKS only blocks procfs-style "symlinks" (filesystem
"symlinks" that call nd_jump_link() themselves -- currently only
procfs and nsfs).
The reason why we need AT_NO_PROCLINKS is that "proclinks"[*] allow for
breaking-out of nd->root without a trivial way of detecting it (since
the filesystem can manipulate nd->path almost arbitrarily outside of the
control of VFS). Al Viro's original patchset[1] also blocked these but
it was all included within AT_NO_JUMPS.
Requiring you to block *all* symlinks in order to block "proclinks"
seems to be a bit overkill to me (especially if consider that
AT_THIS_ROOT|AT_NO_PROCLINKS is definitely a usecase most container
runtimes would be _very_ interested in -- while AT_NO_SYMLINKS will
cause issues with most distribution images).
[*]: Sorry for the awful naming, I'm not sure what the correct name is
(I've called them "super symlinks" in the past) -- if you have a
better name please let me know!
[1]: https://lwn.net/Articles/721443/
[2]: https://marc.info/?l=linux-kernel&m=149394765324531&w=2
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
