On Thu, Jul 18, 2024 at 12:59:15PM +0100, Stuart Henderson wrote:
> On 2024/07/18 05:27, Theo de Raadt wrote:
> > This is not right.
> > 
> > Only a maximum number of unveil's are allowed, before it starts returning
> > E2BIG.  That amount is not a public #define, to discourage what you are
> > doing.
> > 
> > You are trying to shove an unbounded number of them into the kernel, based
> > upon getenv and argv.
> > 
> > When you run out, and will exit with error.  That's not very nice is it?
> > 
> 
> I think the place where unveil really gives the most benefit is for
> software which needs both network and filesystem access in the same
> process. Much of the protection that Lorenz is looking for would come
> from pledge without needing to consider unveil.

I think unveil might still be useful.
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
>