On 2019-10-07, Jann Horn <jannh@xxxxxxxxxx> wrote: > On Thu, Oct 3, 2019 at 4:56 PM Aleksa Sarai <cyphar@xxxxxxxxxx> wrote: > > Traditionally, magic-links have not been a well-understood topic in > > Linux. Given the new changes in their semantics (related to the link > > mode of trailing magic-links), it seems like a good opportunity to shine > > more light on magic-links and their semantics. > [...] > > +++ b/man7/symlink.7 > > @@ -84,6 +84,25 @@ as they are implemented on Linux and other systems, > > are outlined here. > > It is important that site-local applications also conform to these rules, > > so that the user interface can be as consistent as possible. > > +.SS Magic-links > > +There is a special class of symlink-like objects known as "magic-links" which > > I think names like that normally aren't hypenated in english, and > instead of "magic-links", it'd be "magic links"? Just like how you > wouldn't write "symbolic-link", but "symbolic link". But this is > bikeshedding, and if you disagree, feel free to ignore this comment. Looking at it now, I think you're right -- I hyphenated it here because that's how I wrote it when documenting the feature in comments. But I think that's because "symlink" and "magic-link" (the "abbreviated" versions) seem to match better than "symlink" and "magic link". I'll use "magic link" in documentation, but "magic-link" for all cases where I would normally write "symlink". > > +can be found in certain pseudo-filesystems such as > > +.BR proc (5) > > +(examples include > > +.IR /proc/[pid]/exe " and " /proc/[pid]/fd/* .) > > +Unlike normal symlinks, magic-links are not resolved through > > nit: AFAICS symlinks are always referred to as "symbolic links" > throughout the manpages. :+1: > > +pathname-expansion, but instead act as direct references to the kernel's own > > +representation of a file handle. As such, these magic-links allow users to > > +access files which cannot be referenced with normal paths (such as unlinked > > +files still referenced by a running program.) > > Could maybe add "and files in different mount namespaces" as another > example here; at least for me, that's the main usecases for > /proc/*/root. Will do. > [...] > > +However, magic-links do not follow this rule. They can have a non-0777 mode, > > +which is used for permission checks when the final > > +component of an > > +.BR open (2)'s > > Maybe leave out the "open" part, since the same restriction has to > also apply to other syscalls operating on files, like truncate() and > so on? Yes (though I've just realised I hadn't implemented that -- oops.) Given how expansive this patchset will get -- I might end up splitting it into the magic-link stuff (and O_EMPTYPATH) and a separate series for openat2(2) and the path resolution restrictions. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
