Tobias Heider <tobias.heider@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.