|
|
Subscribe / Log in / New account

Restricting path name lookup with openat2()

Restricting path name lookup with openat2()

Posted Aug 24, 2019 5:40 UTC (Sat) by cyphar (subscriber, #110703)
In reply to: Restricting path name lookup with openat2() by epa
Parent article: Restricting path name lookup with openat2()

With the downside that using the syscall would be more frustrating -- users that don't care about resolution would need to pass an extra 0 all the time (and the upgrade_mask union would be quite ugly to use too). Not to mention that there is a limit on the number of syscall arguments (6), so in the future we would probably need to switch to a struct-based argument anyway. Linus also mentioned in an earlier review that he wasn't a fan of the variadic open(2) semantics -- so I would like to avoid carrying that syscall design forward as well.

This isn't all a hypothetical -- my first draft of the syscall did just add a new argument, and I discovered pretty quickly (while writing the selftests) that it was abysmal to actually use that interface. The fact that C zeroes out structs when you do designated initialisation makes using structs so much more straightforward here. All of that being said, I'm not married to the current interface at all. If the only concern people have with the patches is what the syscall looks like, I'm more than happy to change it.


to post comments

Restricting path name lookup with openat2()

Posted Aug 24, 2019 8:00 UTC (Sat) by epa (subscriber, #39769) [Link] (1 responses)

When I said a ‘flag’ I didn’t mean it had to be an extra argument. A Boolean flag can be passed in lots of ways, including a bitmask of flags, and could be part of a struct. What I meant was, in addition to all the funky options mentioned in the article to stop following ‘magic links’ and so on, there could be one more to stop following any directory traversal whatever.

Restricting path name lookup with openat2()

Posted Aug 24, 2019 8:26 UTC (Sat) by cyphar (subscriber, #110703) [Link]

Oh, I'm really sorry -- I completely misread the rest of the comment thread I was responding to. I thought you were arguing for not having a struct *at all* (as someone else has suggested in a separate thread) and that's what I was talking about. Yes, a RESOLVE_NO_SUBDIRS (or whatever) could be useful -- though I'd prefer to land openat2() first and then we can work on extensions like that (I'm already worried enough that the patch touches too many things).


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds