Hacker News Reader

Comment by gshrikant | Hacker News Reader

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.

View on HN

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, 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();

> 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.

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

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

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

what do the 0,0 mean here?

Disallows further use of unveil()

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.

Tbh, to me the title "Unveil parts of a restricted filesystem view" read like it was about a hack.

Yeah, that was my thought too. This is more like “veil_except”.

That said, “unveil” is good enough.

Why not "restrict"?

Here be dragons! "restrict" is a keyword in C.

I agree. Naming things is so hard. It's always nice when people do manage to come up with terse names.

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.

Pledge (previously `tame`) did use bitmasks in its earlier iterations. See Ted Unangst's post about it: https://www.tedunangst.com/flak/post/string-interfaces

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.

I don't like it, it's un-C-like.

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.

Maybe Theo wanted fopen-like semantics?

fopen is not a system call, it is a library call. The system call is open, and it uses bits for flags.

Which makes it that much harder to extend.

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.

But compiler errors (typo in a flag) become runtime errors (typo in the unveil string).

You're only one character away from FLAG1 || FLAG2.

It is trivial to run a script to check the values are correct.

It's also pretty trivial to run the program. Maybe it's different in other projects, but I'm pretty sure in OpenBSD you're encouraged to actually test the code, not just ship it because it compiles. There's 2 programs in OpenBSD's base that don't abort on the pledge call failing, they're both shells, and they don't fail quietly.

You don't see an issue with needing to write and maintain a verification script for something that is essentially a solved problem? Why add more development runtime overhead? What do string-based flags get you that bit-based don't?

Removes the need to add a separate include for namespacing, ie. no pledge.h header needed.

Makes the calls shorter and easier to read. Consider:

    if (pledge("stdio rpath tmppath proc exec", NULL) == -1)
        err(1, "pledge");

vs.

    if (pledge(PLEDGE_STDIO | PLEDGE_RPATH | PLEDGE_TMPPATH | PLEDGE_PROC | PLEDGE_EXEC, NULL) == -1)
        err(1, "pledge");

Makes it easier to add a pledge interface to other languages with having to keep chasing bit flag changes, ie. there's been several new promises add since 2015 but the OpenBSD::Pledge perl module hasn't needed to change.

And really, unless you're using pledge wrong, ie. by using it outside of the startup path and/or not checking the return value, what does compile-time checking get you?

Nope, I really don't. I don't fear strings in code because I have to run verification scripts on whatever config format we end up using or you get stuff like [1]. Its just another part of the compile process once setup, and their reasoning was sound[2], so why stress. Heck, the script isn't even complicated.

Now, at a language level, would I like the C committee to start looking at some of these things? Yes, but why bother hoping for miracles.

1) https://www.engadget.com/2018/07/13/aliens-colonial-marines-...

2) https://www.tedunangst.com/flak/post/string-interfaces

If I’m not mistaken, you can even have the best of both worlds in languages with proper macro support (I’m sure you know which lang I‘m talking about): The Macro call can take the string input and „desugar“ it into bitmasks / function calls / whatever you need at compile time. Then you have:

1) easily readable, string-like input; 2) built-in-your-code verification and 3) compile-time check; 4) zero-overhead execution.

Just reading Ted‘s blog post gave me an idea how lang-specific libraries / (thin-layer) abstractions (or simply additional magic helper functionality) can improve upon legacy API designs (e.g. the GLX example) by using lang-specific functionality I never knew I‘d need or even cared about. Sometimes one can learn when you‘d never expect it. :D

Unless I‘m mistaken and misunderstood the whole thing, please correct me in that case.

I think the issue is that for most languages you have to update the libraries with the new constants for bit-wise operations and not for the string approach. Some languages would be fine, but this is multi-language in the end.

Reply on news.ycombinator.com