How to handle postinst scripts that touch /dev/

ev3dev / brickstrap

Tool for bootstrapping Debian and creating bootable image files for embedded systems

MIT License

35 stars 26 forks source link

How to handle postinst scripts that touch /dev/ #51

Closed dlech closed 7 years ago

dlech commented 8 years ago

I have recently run across a couple packages that try to chmod nodes in /dev/. Since we have the host system's /dev mounted, this fails (as it should). Technically, these should be considered bugs against the debian package. So, the question is what to do about it?

We could add pre-configure hooks that edit the postinst scripts.
We could just say that you should create a fixed up package instead.
We could try to just bind mount essential nodes in /dev like /dev/null instead of mounting the entire directory from the host system.

cmacq2 commented 8 years ago

We could try to just bind mount essential nodes in /dev like /dev/null instead of mounting the entire directory from the host system.

Makes sense. AFAIK that is also what systemd-nspawn does and it makes a good deal of sense to 'match' systemd behaviour whenever feasible because systemd-nspawn/machined containers probably get a lot more testing/packaging love from Debian & upstreams than plain, homegrown LXC configs.

cmacq2 commented 8 years ago

We could add pre-configure hooks that edit the postinst scripts.

That ... strikes me as very fragile/error prone, not to mention hard to test exhaustively.

dlech commented 8 years ago

Yeah, it sounds like we should be using system-nspawn instead of user-unshare. It's only available in stretch/wily though and I'm still on trusty. Might be something to consider when xenial comes out.

cmacq2 commented 8 years ago

Problem seems to be that systemd-nspawn requires elevated privs though...

dlech commented 7 years ago

not an issue anymore since we are using docker for bootstraping