add no-pty-setowner option in authorized_keys

[rd235]

My goal is to use dropbear to log-in into unprivileged network namespaces (like those created by vdens: https://github.com/rd235/vdens )

Dropbear's pty supports fails as in unprivileged namespaces the group ownership of /dev/pty/* is remapped to "nogroup" (instead of "tty"). So the condition in sshpty.c:

385   if (st.st_uid != pw->pw_uid || !(st.st_gid == gid || st.st_gid == pw->pw_gid)) {

is true, and then it tries to chown the pty file:

386     if (chown(tty_name, pw->pw_uid, gid) < 0) {

... the session fails because it would require CAPCHOWN that the unprivileged namespace does not own.

There is no need to change the pty ownership for this application (outside a namespace the condition of line 385 would have been false. It is true only due to the gid remapping.)

This pull request defines a new option for the authorized_keys file named "no-pty-setowner". When this option is defined dropbear skips the owner redefinition of the pty special file.

This option enables one further application case for dropbear. Other usages are unaffected (not using the new "no-pty-setowner" option)

[mkj]

Dropbear's pty supports fails as in unprivileged namespaces the group ownership of /dev/pty/* is remapped to "nogroup" (instead of "tty"). So the condition in sshpty.c:

To me it seems like like the correct fix would be to ensure /dev/pts is mounted nogroup. My understanding is that it's best for each namespace to have its own /dev/pts mountpoint, so that could be mounted with uid= option set to the tty user uid.

[mkj]

Sorry, I mean "ensure /dev/pts is not owned by nogroup"

[rd235]

OK. you are right. This problem can have a simpler solution. I'll file a new pull request.