6 ms·

Using Landlock to Sandbox GNU Make

242 points by jart 4y ago

sophacles 4y ago
This is pretty cool! I have a habit of using Makefiles to automate a lot of things that aren't really build systems (it just maps nicely to how i think of a lot of problems - the whole target + dependency graph concept is powerful). While I'm positive that this work is great for build system stuff too, this will certainly also help solve some problems I've created for myself in the past - namely accidentally acting on files I didn't intent to.
djhaskin987 4y ago
I wonder why there was no mention of simply contributing these 200 lines to GNU make proper instead of forking. Super cool though.
- jart 4y ago
  That 200 lines doesn't include our pledge() implementation, which Make assumes is provided by the C library. Right now only Cosmopolitan Libc and OpenBSD have an unveil() implementation. It would take some thought to decide what the best approach would be for incorporating something like that into GNU Make. So I'm waiting on more feedback from the community and the GNU developers. Because upstreaming is totally something I'm open to considering. Also please consider that GNU Make supports so many ancient platforms, like DOS, QDOS, Amiga, Windows 3.1. When I forked GNU Make, the first thing I did was delete all that support for ancient defunct platforms to give me enough room to think about how to approach implementing this feature. I don't think I could have done this if I had to wade through all that code from the start. I'm doing this work just for fun and to help out, and coding is only fun when the code is clean.
  - jonahx 4y ago
    > and coding is only fun when the code is clean. I wish I could upvote this more than one time.
  - dwheeler 4y ago
    I'd like to see this upstream. It's okay if the functionality only works on some platforms... it would force fixing of makefiles, and all platforms would benefit from that result.
  - pabs3 4y ago
    The pledge implementation seems like something that would be useful to other things too, so maybe spin it out into a separate library?
ghoward 4y ago
Good work, but I'm afraid that this will not really catch on because it's not that portable. I also think that Bazel has the same problem; most of the sandboxing works only on Linux. Until something like this works on Windows, it won't get wide adoption. And it is possible to do something like this on Windows. And personally, I would want to avoid the use of GNU make. Nevertheless, this is a step forward for those who have to use GNU make.
- __float 4y ago
  Bazel uses "sandbox-exec" on macOS, and has a more generic POSIX compatible sandbox if you can't use the Linux sandboxing tool too. > And it _is_ possible to do something like this on Windows. Are you able to point to any open source examples of this? Bazel supports Windows, and I'm sure they'd love to be able to support sandboxing on Windows as well.
  - ghoward 4y ago
    It can be done on Windows, but not how Bazel would want to do it. Basically, the sandbox has to be in the interpreter. And I guess I should be clear that it still won't be be as good as on Linux. By the way, what's this "POSIX compatible sandbox"? chroot? That's not POSIX compatible.
    - __float 4y ago
      What interpreter? Why do you assert that it's "not how Bazel would want to do it"? No, it's not chroot -- it uses a tree of symlinks, created specifically for each process being run, that assumes the process isn't trying to escape the 'sandbox' too much. At the end of the day, a _strong_ sandbox is going to require some OS-specific support, and this could be seen as a kind of graceful degradation when there's not a better OS-provided sandboxing tool. (As an aside, your comments seem rather combative and I don't really understand why; we can discuss the merits of this tool without declaring it'll never catch on and won't _do enough_ for your standards.)
      - 4y ago
gray_-_wolf 4y ago
This is definitely interesting and cool, however: > Landlock Make can build code five times faster than Bazel, while offering the same advantages in terms of safety. In other words, you get all the benefits of a big corporation build system, in a tiny lightweight binary that any indie developer can love. In terms of safety, maybe almost (bazel can check if the source files changed during the build, this (afaict) can not). But bazel also provides a lot more (caching, remote builds, ...). So, while cool, read more on it and evaluate it in depth before deciding to replace bazel with this.
- jart 4y ago
  One of the nice things about Bazel that the article didn't get a chance to go into is it uses SHA hashes of files, rather than file timestamps, to determine when an artifact has changed and therefore needs to be updated. It's slightly more costly to compute hashes, but it's necessary if you want to have something like a global cache of build artifacts, since synchronizing time across machines is hard. What I'd recommend for anyone really, is to just do what Google did. For the first six years of Google's lifecycle, they got along just fine with GNU Make. Then they switched to the huge scalable thing once they actually reached that inflection point. I'm obviously not there since I'm just a scrappy open source coder. So for me I'm quite happy to be working with GNU Make and I can foresee myself getting many additional years of use out of it.
  - gravypod 4y ago
    > What I'd recommend for anyone really, is to just do what Google did. For the first decade and a half of Google's company lifecycle, they got along just fine with GNU Make. Then they switched to the huge scalable thing once they actually reached that inflection point. Hopefully as a community we can build things that are scalable and as-simple-as Make. I think please.build is a step in the right direction but still too complicated.
    - chubot 4y ago
      Eh Make is not good for most problems -- see experiences here by dwheeler, me, frankohn: https://news.ycombinator.com/item?id=32301606 https://news.ycombinator.com/item?id=32301606 And this other thread I linked there, with feedback from FreeBSD engineers: https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc --- Ninja basically gives you the parts of GNU make that are good, without the cruft and slowness. And you can learn it in 20 minutes, unlike GNU make
ezekiel68 4y ago
I want to like this (and I do). It just feels like yet another perfectly wonderful tool that only 1000 other people in the world (besides me) will use. Not really sure why that even bothers me.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
brabel 4y ago
Very nice, this is almost exactly the kind of thing I wanted to have to create a higher level build tool (make files are IMO pretty terrible as a declarative language for building, but perhaps a good low level primitive to use to build systems like Bazel on top of). The only problem is the dependency on a fresh Linux feature (ported from OpenBSD if I understand correctly)... my ultimate goal was to have a Landlock thing that works on all OSs, but that may be really hard as not many languages abstract the file system away so that this can be implemented in the application-level (Dart has support for abstracting away the file system, and I was trying to use that, but it doesn't seem to support that kind of thing when running processes). I suspect this should also make things like Nix and Guix easier... or maybe lighter-version of them easier as you don't need to implement the build sandox anymore when building software if you use Landlock Make.
ndriiu- 4y ago
elteto 4y ago
Very interesting and impressive technically but the post took a dive towards the end with the anti-Java rant. We can celebrate our work without having to stand on a platform made by bashing the work of others.
- sneak 4y ago
  That was no rant or bashing, it was short, accurate, and directly relevant to the primary topic of the article.
skybrian 4y ago
One of the downsides of Blaze/Bazel is that the symlink tree adds indirection that makes debugging broken builds that much harder. This approach, while not very portable, seems like a win from an ease of use standpoint. (Also, at least internally, Blaze pretty much required Linux for the longest time anyway.)
BiteCode_dev 4y ago
This comment is a plug. I've tried many alternative to make over the years, and eventually, doit (pydoit.org/) was the one I sticked with. It's declarative yet dynamic, it's simple yet powerful, you get to use shell command or a custom function, and it deals with all the things you need like deps and targets, creating a dag, caching, etc. It's the sweat spot for me.
mtlmtlmtlmtl 4y ago
Justine is one of my fav contemporary hackers. Whenever I see her stuff posted on here, not only am I amazed that anyone did what was done, but even more amazed that one person did it all on their own. Justine, if you're reading this, keep up the amazing work!
- heavyset_go 4y ago
  Agreed. The word "impressed" doesn't accurately capture the way I feel about her work. Her content is exactly the kind of stuff that got me fascinated by CS at a young age, and it's nice feeling that again as an adult, as I almost invariably do whenever I come across something she's written or made.
marcodiego 4y ago
I hope landlock brings a simple unveil and pledge.
spockz 4y ago
The only thing I’m really missing for my usecase with make is the ability to specify goals/targets other than files. E.g., I want a docker image to be present in the daemon. Basically, calling out to a function. (Probably somebody is going to correct me and say there is something there in the form of conditionals or something..)
- shakna 4y ago
  GNU Make has Guile built-in, so you've got the whole of Scheme (the language), if you want to do something a bit more complicated.
- avar 4y ago
  That's easy to do, but if you want to make it compatible with incremental builds the best way is to create a "I did it already" empty file as a dependency marker. E.g. "build" a ". build/called/apt-install-deps" or whatever.
  - spockz 4y ago
    This is exactly how I do it now but it is brittle. If either my packages are changed, or the definition of what needs to be installed/pulled changes I need either remove the file or something. I could maybe put all these definitions, packages etc in separate files and then have make watch the time stamps. That saves the issue of changing definitions but doesn’t help when things get deleted from under your feet.
- enriquto 4y ago
  > E.g., I want a docker image to be present in the daemon. This sounds more like a limitation of docker than of make. I don't use docker, but how on earth something called a "docker image" is not a file?
  - spockz 4y ago
    Docker images can be stored as a file. And maybe are indeed stored on the file system as individual files as well. But building against a specific cr implementation for this seems too brittle.
now 4y ago
Could you please explain the `o//` “convention”?
Toaster-King 4y ago
Wow. Strange seeing something I helped with on the front page of HN[1]. Thanks for the shoutout Justine! [1] https://github.com/jart/cosmopolitan/pull/490 https://github.com/jart/cosmopolitan/pull/490
- jart 4y ago
  Thank you for helping!
benreesman 4y ago
Others have said similar things, so my point is mostly one of emphasis. Bazel goes deep on finding edges in the build graph. Example: C/C++ has this preprocessor step where ‘#include’ and stuff happen. It’s very cheap compared to what comes next. If you change white space or comments or whatever, the preprocessor runs, hashes the same, now the .o is good, now the link is good. OP’s stuff is cool, but just wanted to make sure everyone is clear that industrial strength build systems like Bazel take on that constant factor intentionally. They are designed for building big, complex, polyglot code bases.
dwheeler 4y ago
This is very cool. A while back I started an experiment/prototype called "make-audit"; this is a (draft) tool to report when an execution of GNU make reads or changes files in ways that are inconsistent with its Makefile: https://github.com/david-a-wheeler/make-audit https://github.com/david-a-wheeler/make-audit It's nowhere ready for serious use, but it can detect the following: * Error: Target TARGET : unreported prerequisites: SET : The make recipe for creating TARGET is reading from the prerequisites in SET, but the makefile fails to report them as dependencies. You may want to add SET to the prerequisites of TARGET. * Error: Target TARGET : claimed but unused prerequisites: SET : The make recipe for creating TARGET claims that it depends on SET, but the items in SET were never read. You may want to remove SET from the prerequisites of TARGET. * Error: Target TARGET : unreported target: SET The make recipe for updating TARGET also modifies the files in SET but this is not reported. * Error: Target TARGET : unmodified reported target: SET This depended on Poor Man's File Auditor (pmaudit): https://github.com/boyski/pmaudit https://github.com/boyski/pmaudit

242 points by jart 4y ago

This is pretty cool! I have a habit of using Makefiles to automate a lot of things that aren't really build systems (it just maps nicely to how i think of a lot of problems - the whole target + dependency graph concept is powerful). While I'm positive that this work is great for build system stuff too, this will certainly also help solve some problems I've created for myself in the past - namely accidentally acting on files I didn't intent to.

djhaskin987 4y ago

I wonder why there was no mention of simply contributing these 200 lines to GNU make proper instead of forking. Super cool though.

jart 4y ago
That 200 lines doesn't include our pledge() implementation, which Make assumes is provided by the C library. Right now only Cosmopolitan Libc and OpenBSD have an unveil() implementation. It would take some thought to decide what the best approach would be for incorporating something like that into GNU Make. So I'm waiting on more feedback from the community and the GNU developers. Because upstreaming is totally something I'm open to considering. Also please consider that GNU Make supports so many ancient platforms, like DOS, QDOS, Amiga, Windows 3.1. When I forked GNU Make, the first thing I did was delete all that support for ancient defunct platforms to give me enough room to think about how to approach implementing this feature. I don't think I could have done this if I had to wade through all that code from the start. I'm doing this work just for fun and to help out, and coding is only fun when the code is clean.
- jonahx 4y ago
  > and coding is only fun when the code is clean. I wish I could upvote this more than one time.
- dwheeler 4y ago
  I'd like to see this upstream. It's okay if the functionality only works on some platforms... it would force fixing of makefiles, and all platforms would benefit from that result.
- pabs3 4y ago
  The pledge implementation seems like something that would be useful to other things too, so maybe spin it out into a separate library?

ghoward 4y ago

Good work, but I'm afraid that this will not really catch on because it's not that portable. I also think that Bazel has the same problem; most of the sandboxing works only on Linux. Until something like this works on Windows, it won't get wide adoption. And it is possible to do something like this on Windows. And personally, I would want to avoid the use of GNU make. Nevertheless, this is a step forward for those who have to use GNU make.

__float 4y ago
Bazel uses "sandbox-exec" on macOS, and has a more generic POSIX compatible sandbox if you can't use the Linux sandboxing tool too. > And it _is_ possible to do something like this on Windows. Are you able to point to any open source examples of this? Bazel supports Windows, and I'm sure they'd love to be able to support sandboxing on Windows as well.
- ghoward 4y ago
  It can be done on Windows, but not how Bazel would want to do it. Basically, the sandbox has to be in the interpreter. And I guess I should be clear that it still won't be be as good as on Linux. By the way, what's this "POSIX compatible sandbox"? chroot? That's not POSIX compatible.
  - __float 4y ago
    What interpreter? Why do you assert that it's "not how Bazel would want to do it"? No, it's not chroot -- it uses a tree of symlinks, created specifically for each process being run, that assumes the process isn't trying to escape the 'sandbox' too much. At the end of the day, a _strong_ sandbox is going to require some OS-specific support, and this could be seen as a kind of graceful degradation when there's not a better OS-provided sandboxing tool. (As an aside, your comments seem rather combative and I don't really understand why; we can discuss the merits of this tool without declaring it'll never catch on and won't _do enough_ for your standards.)
    - 4y ago

gray_-_wolf 4y ago

This is definitely interesting and cool, however: > Landlock Make can build code five times faster than Bazel, while offering the same advantages in terms of safety. In other words, you get all the benefits of a big corporation build system, in a tiny lightweight binary that any indie developer can love. In terms of safety, maybe almost (bazel can check if the source files changed during the build, this (afaict) can not). But bazel also provides a lot more (caching, remote builds, ...). So, while cool, read more on it and evaluate it in depth before deciding to replace bazel with this.

jart 4y ago
One of the nice things about Bazel that the article didn't get a chance to go into is it uses SHA hashes of files, rather than file timestamps, to determine when an artifact has changed and therefore needs to be updated. It's slightly more costly to compute hashes, but it's necessary if you want to have something like a global cache of build artifacts, since synchronizing time across machines is hard. What I'd recommend for anyone really, is to just do what Google did. For the first six years of Google's lifecycle, they got along just fine with GNU Make. Then they switched to the huge scalable thing once they actually reached that inflection point. I'm obviously not there since I'm just a scrappy open source coder. So for me I'm quite happy to be working with GNU Make and I can foresee myself getting many additional years of use out of it.
- gravypod 4y ago
  > What I'd recommend for anyone really, is to just do what Google did. For the first decade and a half of Google's company lifecycle, they got along just fine with GNU Make. Then they switched to the huge scalable thing once they actually reached that inflection point. Hopefully as a community we can build things that are scalable and as-simple-as Make. I think please.build is a step in the right direction but still too complicated.
  - chubot 4y ago
    Eh Make is not good for most problems -- see experiences here by dwheeler, me, frankohn: https://news.ycombinator.com/item?id=32301606 https://news.ycombinator.com/item?id=32301606 And this other thread I linked there, with feedback from FreeBSD engineers: https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc --- Ninja basically gives you the parts of GNU make that are good, without the cruft and slowness. And you can learn it in 20 minutes, unlike GNU make

ezekiel68 4y ago

I want to like this (and I do). It just feels like yet another perfectly wonderful tool that only 1000 other people in the world (besides me) will use. Not really sure why that even bothers me.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

brabel 4y ago

Very nice, this is almost exactly the kind of thing I wanted to have to create a higher level build tool (make files are IMO pretty terrible as a declarative language for building, but perhaps a good low level primitive to use to build systems like Bazel on top of). The only problem is the dependency on a fresh Linux feature (ported from OpenBSD if I understand correctly)... my ultimate goal was to have a Landlock thing that works on all OSs, but that may be really hard as not many languages abstract the file system away so that this can be implemented in the application-level (Dart has support for abstracting away the file system, and I was trying to use that, but it doesn't seem to support that kind of thing when running processes). I suspect this should also make things like Nix and Guix easier... or maybe lighter-version of them easier as you don't need to implement the build sandox anymore when building software if you use Landlock Make.

ndriiu- 4y ago

elteto 4y ago

Very interesting and impressive technically but the post took a dive towards the end with the anti-Java rant. We can celebrate our work without having to stand on a platform made by bashing the work of others.

sneak 4y ago
That was no rant or bashing, it was short, accurate, and directly relevant to the primary topic of the article.

skybrian 4y ago

One of the downsides of Blaze/Bazel is that the symlink tree adds indirection that makes debugging broken builds that much harder. This approach, while not very portable, seems like a win from an ease of use standpoint. (Also, at least internally, Blaze pretty much required Linux for the longest time anyway.)

BiteCode_dev 4y ago

This comment is a plug. I've tried many alternative to make over the years, and eventually, doit (pydoit.org/) was the one I sticked with. It's declarative yet dynamic, it's simple yet powerful, you get to use shell command or a custom function, and it deals with all the things you need like deps and targets, creating a dag, caching, etc. It's the sweat spot for me.

mtlmtlmtlmtl 4y ago

Justine is one of my fav contemporary hackers. Whenever I see her stuff posted on here, not only am I amazed that anyone did what was done, but even more amazed that one person did it all on their own. Justine, if you're reading this, keep up the amazing work!

heavyset_go 4y ago
Agreed. The word "impressed" doesn't accurately capture the way I feel about her work. Her content is exactly the kind of stuff that got me fascinated by CS at a young age, and it's nice feeling that again as an adult, as I almost invariably do whenever I come across something she's written or made.

marcodiego 4y ago

I hope landlock brings a simple unveil and pledge.

spockz 4y ago

The only thing I’m really missing for my usecase with make is the ability to specify goals/targets other than files. E.g., I want a docker image to be present in the daemon. Basically, calling out to a function. (Probably somebody is going to correct me and say there is something there in the form of conditionals or something..)

shakna 4y ago
GNU Make has Guile built-in, so you've got the whole of Scheme (the language), if you want to do something a bit more complicated.
avar 4y ago
That's easy to do, but if you want to make it compatible with incremental builds the best way is to create a "I did it already" empty file as a dependency marker. E.g. "build" a ". build/called/apt-install-deps" or whatever.
- spockz 4y ago
  This is exactly how I do it now but it is brittle. If either my packages are changed, or the definition of what needs to be installed/pulled changes I need either remove the file or something. I could maybe put all these definitions, packages etc in separate files and then have make watch the time stamps. That saves the issue of changing definitions but doesn’t help when things get deleted from under your feet.
enriquto 4y ago
> E.g., I want a docker image to be present in the daemon. This sounds more like a limitation of docker than of make. I don't use docker, but how on earth something called a "docker image" is not a file?
- spockz 4y ago
  Docker images can be stored as a file. And maybe are indeed stored on the file system as individual files as well. But building against a specific cr implementation for this seems too brittle.

now 4y ago

Could you please explain the `o//` “convention”?

Toaster-King 4y ago

Wow. Strange seeing something I helped with on the front page of HN[1]. Thanks for the shoutout Justine! [1] https://github.com/jart/cosmopolitan/pull/490 https://github.com/jart/cosmopolitan/pull/490

jart 4y ago
Thank you for helping!

benreesman 4y ago

Others have said similar things, so my point is mostly one of emphasis. Bazel goes deep on finding edges in the build graph. Example: C/C++ has this preprocessor step where ‘#include’ and stuff happen. It’s very cheap compared to what comes next. If you change white space or comments or whatever, the preprocessor runs, hashes the same, now the .o is good, now the link is good. OP’s stuff is cool, but just wanted to make sure everyone is clear that industrial strength build systems like Bazel take on that constant factor intentionally. They are designed for building big, complex, polyglot code bases.

dwheeler 4y ago

This is very cool. A while back I started an experiment/prototype called "make-audit"; this is a (draft) tool to report when an execution of GNU make reads or changes files in ways that are inconsistent with its Makefile: https://github.com/david-a-wheeler/make-audit https://github.com/david-a-wheeler/make-audit It's nowhere ready for serious use, but it can detect the following: * Error: Target TARGET : unreported prerequisites: SET : The make recipe for creating TARGET is reading from the prerequisites in SET, but the makefile fails to report them as dependencies. You may want to add SET to the prerequisites of TARGET. * Error: Target TARGET : claimed but unused prerequisites: SET : The make recipe for creating TARGET claims that it depends on SET, but the items in SET were never read. You may want to remove SET from the prerequisites of TARGET. * Error: Target TARGET : unreported target: SET The make recipe for updating TARGET also modifies the files in SET but this is not reported. * Error: Target TARGET : unmodified reported target: SET This depended on Poor Man's File Auditor (pmaudit): https://github.com/boyski/pmaudit https://github.com/boyski/pmaudit