4 ms·
I'm intrigued by the idea, but I think this only replaces sudo, and set[ug]id is related but not identical? What I am thinking of is that set[ug]id should alre
by enasterosophes 3y ago
I'm intrigued by the idea, but I think this only replaces sudo, and set[ug]id is related but not identical?
What I am thinking of is that set[ug]id should already be superseded by capabilities(7). Now, I know CAP_SYS_ADMIN gets flak for being too overpowered and not being better than sudo. However, there are other capabilities which are sometimes sufficient. For example, slock used to require setuid, but now it is sufficent to add CAP_DAC_READ_SEARCH and CAP_SYS_RESOURCE to the generated binary.
So, as cool as the idea is, when it comes to setuid/setgid, I don't see what it gives me relative to capabilities.
The more interesting use case, from where I'm sitting, is that it makes it easy to use a yubikey for 2FA access to sudo, whereas until now I only heard about needing to muck around with PAM.
Edit: Ah, I just re-read the lede and I think I misunderstood what the article was going for. It's not talking about replacing set[ug]id in general, it's using the stigma of set[ug]id as a motivation for replacing sudo. That's probably not the way I would have chosen to motivate the technique, but I can also see that my above criticism was ill-premised.