Hacker News new | ask | show | jobs
by rollcat 1038 days ago
The issue with implementing that on traditional UNIX systems is that only root can impersonate another user. (Mechanisms such as su/sudo are achieving their goal through a setuid bit, and implement a policy using executable code in user space, which historically hasn't been without its own share of bugs.)

Next problem will be sharing data between programs that legitimately need to do so; if I had an _emacs user that owned my source code, how do I make it non-painful for the _gcc user to read the source and write the resulting executables (which would end up in a directory owned by _emacs)? What about git, various preprocessors/generators, formatters, linters?

You'd have to step out of the traditional UNIX authn/authz model to effectively implement that. It's what various security-focussed OS's have been doing for a while anyway; e.g. OpenBSD implements unveil, which "hides" entire branches of the VFS tree. For example, if git has no business reading or writing files outside of the currently operated on repository, it can restrict itself very early in the process life - before proceeding to perform any of the "tricky" operations that are the common sources of security bugs.