[jakobegger]

While it implicitely hides everything on the first call, it unveils the arguments. Reads really natural. I imagine typical usage would be:

    fork();
    unveil("/home/jakob/", "w");
    unveil("/etc/some_config_file", "r");
    unveil(0,0);
    exec();

[masklinn]

> While it implicitely hides everything on the first call

I think that's the really weird bit, I guess they didn't want multiple functions but it would make more sense to veil() (hide everything), unveil(path, mode) (show that path) and lockveil(), something along those lines. Or maybe use some sort of mode constants e.g. veil(VEIL_INIT), veil(VEIL_REVEAL, path, mode), veil(VEIL_LOCK).

[jakobegger]

What benefit would requiring veil() before unveil() have? There is no point in calling unveil() if the file system isn't hidden. Making the hiding implicit reduces the number of possible mistakes people can make when using the API.

[daveFNbuck]

You could be more sure that something else didn't already unveil things you want hidden in your current invocation.

[shoo]

The end game might be that everything is veiled by default, so if you have no unveil calls then your process can't read anything

[masklinn]

That would work just as well with a better API. The initial call would just become a no-op at that point.

[apengwin]

what do the 0,0 mean here?

[r1ch]

Disallows further use of unveil()