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.
