GNOME Bugzilla – Bug 722001
unbreak ssh password login on BSDs
Last modified: 2014-01-17 13:11:37 UTC
Hi. On BSD systems (confirmed on at least FreeBSD and OpenBSD), the ssh dialogues are not properly displayed (e.g. for G_ASK_PASSWORD_SAVING_SUPPORTED, or accepting login to a new host which we have no known_hosts entry for) for login/pass connections (ssh-key works fine). In the case we have SSH_ASKPASS set in the environment, then it will use that of course, but I'd rather fix the native behavior. I was able to workaround this behavior by doing the following: --- daemon/pty_open.c.orig Thu Nov 7 16:12:17 2013 +++ daemon/pty_open.c Sat Jan 11 17:54:26 2014 @@ -72,7 +72,7 @@ #include <glib.h> #include "pty_open.h" -#if defined(HAVE_PTSNAME_R) || defined(HAVE_PTSNAME) || defined(TIOCGPTN) +#if (defined(HAVE_PTSNAME_R) || defined(HAVE_PTSNAME) || defined(TIOCGPTN)) && !defined(HAVE_OPENPTY) #define HAVE_UNIX98_PTY #else This forces the use of openpty(3). Of course this is not a good patch since Linux also has openpty(3) and will match -- it just put it here for demonstration. I am not sure about the reason why it does not work on BSD systems, but it may be because of this (extract from grantpt man page -- same on OpenBSD and FreeBSD): This implementation of grantpt() and unlockpt() does not conform to IEEE Std 1003.1-2008 (``POSIX.1''), because it depends on posix_openpt(3) to create the pseudo-terminal device with proper permissions in place. It only validates whether fildes is a valid pseudo-terminal master device. We also lack ptsname_r (not sure if that matters for that particular case). Or maybe it is just that the openpty(3) code path keep the slave open as a controlling terminal for the authentication... It really is not my area. Anyway, I was wondering what would be the best way to force OPENPTY on BSD systems -- I can ifdef OpenBSD and FreeBSD of course, but in case you can think of a better way... Thanks a lot for any input.
Created attachment 266356 [details] [review] force openpty(3) on BSD Could the following patch be considered? Thanks.
Review of attachment 266356 [details] [review]: #if defined(HAVE_PTSNAME_R) || defined(HAVE_PTSNAME) || defined(TIOCGPTN) #define HAVE_UNIX98_PTY #else This check is there from reason you mentioned in the first comment. It is added to allow openpty on BSD systems. So the macro HAVE_UNIX98_PTY shouldn't be defined there... See https://bugzilla.gnome.org/show_bug.cgi?id=679790 So don't know, why the macro is defined. Would be better to fix this check and don't set HAVE_UNIX98_PTY if we don't really have it. I don't like the solution based on the operating system macros...
(In reply to comment #2) > Review of attachment 266356 [details] [review]: Hi Ondrej. Thanks a lot for replying. > #if defined(HAVE_PTSNAME_R) || defined(HAVE_PTSNAME) || defined(TIOCGPTN) > #define HAVE_UNIX98_PTY > #else > > This check is there from reason you mentioned in the first comment. It is added > to allow openpty on BSD systems. Not exactly. It was added for OSes that lacked grantpt(3) but had openpty(3). Which was the case in the past for OpenBSD. > So the macro HAVE_UNIX98_PTY shouldn't be > defined there... > > See https://bugzilla.gnome.org/show_bug.cgi?id=679790 I am aware of that patch, it was a joint work from me and Martin (the op). > So don't know, why the macro is defined. Would be better to fix this check and > don't set HAVE_UNIX98_PTY if we don't really have it. I don't like the solution > based on the operating system macros... The bug report you mentioned added openpty(3) support for OSes not having grantpt(3) and friends which was (but is not anymore) the case on OpenBSD. And I want exactly what the patch in the bug report you linked has, that is use openpty(3). Both OpenBSD and FreeBSD have grantpt(3) but both implementations are not 100% conform. This is why they match HAVE_UNIX98_PTY. I am not aware of a way to detect the implementation differences though... besides the #ifdef on OS macros.
Review of attachment 266356 [details] [review]: Ok, the code is full of macros, so please commit to fix the problem for bsd users.
> Ok, the code is full of macros, so please commit to fix the problem for bsd > users. Thank you very much Ondrej. It's in: 9f5585c3d73e7013ad4e9b0e065e75646daf1bc6