Messages in this thread | | | From | "Michael Kerrisk (man-pages)" <> | Date | Wed, 15 Apr 2020 22:24:00 +0200 | Subject | Re: [PATCH man-pages v2 2/2] openat2.2: document new openat2(2) syscall |
| |
Hello Aleksa,
On Tue, 14 Apr 2020 at 12:35, Aleksa Sarai <asarai@suse.de> 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/[...]
| |