Stuart Henderson <stu@spacehopper.org> wrote:
> 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.
I don't agree.
It is extremely rare to just change the pledge strings. The position
of other code has to be adapted. That usually results in one or two files
needing to be recompiled.
I don't agree, because I don't believe that is the process that leads
to privsep using pledge and unveil.
> 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'm making the point that these should be embedded in the binary.
Users cannot change these, because the pledge strings are TIGHLY coupled
to the behavior of the code.
Other programs don't do this.
These files were part or the original development process.
I do not believe they are part of the current development process.
What is happening is power-user find these, and change them, and then they
create problems. The reason is that these files don't stand alone.
> 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.
What do you mean "if" and "_in addition_".
Because that is exactly how unveil works. More refined paths always create
enclaves inside enclaves, with the new permissions. If the paths as
previously specified paths, it replaces the previously specified path.
I really don't see any reason to have these files user visible or editable.
No comments:
Post a Comment