Hello Aleksa, On Tue, 14 Apr 2020 at 12:35, Aleksa Sarai <asarai@xxxxxxx> wrote: [...] > > >> I must admit that I'm still confused. There's only the briefest of > > >> mentions of magic links in symlink(7). Perhaps that needs to be fixed? > > > > > > It wouldn't hurt to add a longer description of magic-links in > > > symlink(7). I'll send you a small patch to beef up the description (I > > > had planned to include a longer rewrite with the O_EMPTYPATH patches but > > > those require quite a bit more work to land). > > > > That would be great. Thank you! > > I'll cook something up later this week. Thank you! [...] > > I've reworked the text on RESOLVE_NO_MAGICLINKS substantially: > > > > RESOLVE_NO_MAGICLINKS > > Disallow all magic-link resolution during path reso‐ > > lution. > > > > Magic links are symbolic link-like objects that are > > most notably found in proc(5); examples include > > /proc/[pid]/exe and /proc/[pid]/fd/*. (See sym‐ > > link(7) for more details.) > > > > Unknowingly opening magic links can be risky for > > some applications. Examples of such risks include > > the following: > > > > · If the process opening a pathname is a controlling > > process that currently has no controlling terminal > > (see credentials(7)), then opening a magic link > > inside /proc/[pid]/fd that happens to refer to a > > terminal would cause the process to acquire a con‐ > > trolling terminal. > > > > · In a containerized environment, a magic link > > inside /proc may refer to an object outside the > > container, and thus may provide a means to escape > > from the container. > > > > [The above example derives from https://lwn.net/Articles/796868/] > > > > Because of such risks, an application may prefer to > > disable magic link resolution using the > > RESOLVE_NO_MAGICLINKS flag. > > > > If the trailing component (i.e., basename) of path‐ > > name is a magic link, and how.flags contains both > > O_PATH and O_NOFOLLOW, then an O_PATH file descrip‐ > > tor referencing the magic link will be returned. > > > > How does the above look? > > The changes look correct, though you could end up going through procfs > even if you weren't resolving a path inside proc directly (since you can > bind-mount symlinks or have a symlink to procfs). But I'm not sure if > it's necessary to outline all the ways a program could be tricked into > doing something unintended. Yes, indeed. These paragraphs are merely intended to give the reader some ideas about what the issues are. > > Also, regarding the last paragraph, I have a question. The > > text doesn't seem quite to relate to the rest of the discussion. > > Should it be saying something like: > > > > If the trailing component (i.e., basename) of pathname is a magic link, > > **how.resolve contains RESOLVE_NO_MAGICLINKS,** > > and how.flags contains both O_PATH and O_NOFOLLOW, then an O_PATH > > file descriptor referencing the magic link will be returned. > > > > ? > > Yes, that is what I meant to write -- Good. Fixed. > and I believe that the > RESOLVE_NO_SYMLINKS section is missing similar text in the second > paragraph (except it should refer to RESOLVE_NO_SYMLINKS, obviously). Also fixed. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/[...]
