Re: pledge/unveil for harec?

[Vevy Kod]

How about adding an environment variable containing all directories where headers can be found ? If it is not provided, we can fall back to the per-file algorithm, possibly going above limit. If a user goes above that limit, they can provide their own list of directories. And in the worst case, they can simply set it to '/', giving themselves read access to everything.

On 18/07/2024 17:43, Lorenz (xha) wrote:

the HARE_TD_<files> are the "typedef" files, basically the equivalent
to C headers, but automatically generated by the compiler so we can
do resolution of types/functions/etc. in dependencies without having
to look at the source files themselves.

i doubt that anyone is ever going to make use of more than 125 imports.

the problem is that i cannot simply restict that to one folder. they
could be anywhere (even though they are not usually). that'd complicate
the patch a lot for... allowing more than 125 imports?

the error message will not be particularly hard to read; i guess if
someone really hits the limit, we can do something about it then?

we don't want to do anything in upstream harec because we want to
keep it to the POSIX subset.

On Thu, Jul 18, 2024 at 09:29:39AM -0600, Theo de Raadt wrote:

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.

OpenPGP_0x02796D87FACEDF43.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature