Not a very insightful comment but I really like the way OpenBSD names system calls - both `unveil` and `pledge` are great, descriptive Unix-y names for what these system calls do.
I'm curious. To me, unveil means reveal information, while the intended purpose for this tool is to hide it. Why do you think it's such a descriptive name?
> 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).
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.
It is stated in the 2nd line of the Description in the manual that this will reveal things with subsequent calls. It’s just the initial call that hides everything.
Reminds me more on Perl naming conventions. Take an arbitrary non technical expression, where established names already do exist, but clash with the semantics.
Also the usage of strings for flags and not int bits just let me cry out. This is pure nonsense.
I know this change, that's why I bothered. He can do this in his private app as he likes, but not in the libc which is the most widely copied libc. It's about security, consistency and being a positive role model.
Too many vowels? Would you prefer 'pldg' ? ;) Unless you meant the stringly-typed arguments in which case I'm 100% with you, they're asking for trouble.
It's like everything else in openbsd. The people who don't use it don't like it; the people who live with it every day for years realize benefits the haters don't perceive.
There's nothing wrong with the use of strings here. It's very readable, easily understandable to anyone who knows C, can be checked by automated tools (or at runtime) for invalid values, and is easily extensible in the future. It's also not on a hot path (I mean, you shouldn't have to do this at any point other than process creation).
Right but is there really any reason why the implementation should call strncmp or anything that would be costlier than a bitwise AND? It's not like "r" reads better than O_RDONLY.
Pledge happens on process startup only, so since it’s not like it is called over and over again during the life of the process, the overhead is certainly negligible for all modern servers, desktops and laptops.