Tobias Heider <tobias.hei...@stusta.de> wrote:
> I think unveil might still be useful.
I don't think so.
> As I understand Theo the problem is just that calling unveil per-input file
> to grant
> read access won't work. Restricting write and create permissions to the single
> well-known output directory still makes sense to me.
>
> >
> > The set of library functions used is pretty small, so it should be easy
> > enough to reason about adding pledge.
> >
> > $ nm -s /usr/local/bin/harec | awk '/^ *U / { print $2 }' | column
> > __assert2 atexit fseek memset strerror
> > __errno bsearch fstat open_memstream strlen
> > __isinf calloc getenv optarg strncmp
> > __isinff exit getline optind strtod
> > __isinfl fclose getopt perror strtoul
> > __isnan feof isalnum qsort
> > strtoumax
> > __isnanf fgetc isalpha realloc vfprintf
> > __isnanl fileno isatty snprintf vsnprintf
> > __isthreaded fmemopen isdigit stat
> > __sF fopen isprint strchr
> > _csu_finish fread memcmp strcmp
> > abort free memcpy strdup
> >
So the undocumented, un-exported, unveil limit today is 128. This comes
with a cost, so we will not be increasing it.
Enough setenv, enough arguments, and it fails. Now how does someone
"workaround"
it in their build tooling?
THAT "workaround" is what makes the solution.
This is not what unveil is intended to support.
