CAP_SETUID and CAP_SETGID is being root in practice: any arbitrary action is possible. I think you are taking the wrong pathEl 5 ago. 2019 12:16, Adam Endrodi <endrodi@xxxxxxxxx> escribió: > > > Dear knowledgeable people, > > > I'm running sshd 6.6.1p1 on RHEL 7.1. I've got a security requirement > to run it as an ordinary user, let's say test-x, instead of root. > It works well if I try to log in as test-x user with public key auth. > > Unfortunately I need sshd to serve other users as well. In order to > let sshd switch uids I've set the CAP_SETUID and CAP_SETGID capabilities > on the sshd binary. But it didn't work out, when I try to log in as > another user, say test-y, sshd says: > > Failed to set uids to 1009. > > Disabling privsep didn't help. From strace I didn't even see any attempt > to setuid() to test-y, so I think (but haven't verified) that when running > as non-root, sshd doesn't even try to change uids. > > My question is, do you think such a use case (running multiuser sshd as > non-root) is possible theoretically, or can it be implemented with a > small patch? > > (Let's not discuss whether the use case makes sense, the requirement for > me is a given.) > > -- > How I need a drink, alcoholic in nature, after the tough chapters > involving quantum mechanics! > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
