On 2026/03/12 10:08, Theo de Raadt wrote:
> I really disagree with this direction.
>
> pledge is not a thing that users should be able to tweak.
>
> The pledge arguments, and more specifically the PLACES where the pledge
> calls happen and the code restructuring to do things before pledge and
> after pledge, is an inate property of the code. USERS CANNOT AND SHOULD
> NOT TOUCH THIS!
>
> We don't have a /etc/bgpd/pledge.config file.
While figuring out how to adjust pledges for code changes, rebuilding
takes a long time (it's still pretty slow even if you have an existing
built tree; even just linking takes a long time) so having them in a
file is still fairly important. Churn is still huge in the code, it's
not like this is software that we are expecting to be fairly static.
But at this point, I don't think they need to be user config files. They
could be hidden away in e.g. /usr/local/chromium and replaced when the
package is updated rather than a user editable @sample'd one in /etc.
(I think the main user edits to these would be if somebody needs to
disable sandbox for some reason, and there's a way to do that anyway).
> Regarding unveil, I think it is also becoming a problem, becausae with the
> recent /dev/null change the system demands a change in the unveils, but they
> are now in a user-modified file.
>
> Robert originally did it this way during pledge, and later unveil, as a
> early development process but I don't think it makes sense anymore.
>
> The flexibility you are proposing here is simply dangerous.
Unveil config would be easier to work with if the file contents were
_in addition_ to a compiled-in default. i.e. the binary already has what
it knows is needed and you can open up some additional files/dirs if
necessary.
No comments:
Post a Comment