Stuart Henderson <stu@spacehopper.org> wrote:
> On 2026/03/12 11:14, Theo de Raadt wrote:
> >
> > > 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.
>
> There are files/paths which are required by the software itself (which
> can be compiled-in),
Obviously.
Same as the pledges.
These unveil paths and these pledge promises are STRONGLY COUPLED with
code behaviours. This is easy to test. Go ahead delete 5 random lines
from an unveil file. Stuff breaks. Delete 1 word from a pledge file.
Stuff breaks. It is not logical to give *ROOT* the ability to change these
for chromium. In the same way, we don't have /etc/sed/unveil and /etc/sed/pledge
configuration files.
> and those required by the user or user's sysadmin.
Can you list the ones required by the user and the user's sysadmin?
But obviously not "the user", because these files are in /etc owned by root.
> The person compiling the package can't know that the user might need to
> use a browser to attach files in /some/nfsserver/docs via webmail, for
> example.
But the user cannot do that in /etc because the files are owned by root.
No comments:
Post a Comment