search for: do_exec_pty

...1. If you start sshd with -r (re-exec disabled), once the daemon is forked to handle a client, the child closes stdin by accident. This causes FD 0 to get re-used by the next open call which eventually you end up with a mess. In the perticual case I saw, the pty fd ended up on FD 0 was closed by do_exec_pty(), pty_make_controlling_tty() then opened a new ttyfd as 0, and do_exec_pty() duped it dup2(0,0), dup2(0,1), dup2(0,2), then called close(ttyfd); which closed 0! Patch against openssh-3.9p1 is attached. -- Dave

Hello, I see that incase of command execution: :fork()" is called twice, in sshd. Once to spin off child sshd from parenat and second from child sshd, to execute command. Due to this I see 3 processes being created for each connection viz: 16398 0.0 0.3 1284 892 ?? S 4:33PM 0:00.05 sshd:child 16399 0.0 0.1 320 232 p4 Is+ 4:33PM 0:00.06 -sh -c foo_command 16401 0.0

For root sessions pam_open_session is called, but not pam_close_session. sshd behavior is broken for root logins because if pam session is run from the child, close is never called due to exec: on open since use_privsep is not set, parent calls do_exec_pty(), which does not open session. then, it skips calling do_setusercontext(), so it does not open session. child calls do_setusercontext(), which opens session. on close child will not close sesion, because it exec'd the shell, and the sshd task is gone! parent will not...

...owed because none of user's group are listed in AllowGroups", + pw->pw_name); return 0; } ga_free(); *** session.c.O Mon Jun 18 13:59:57 2001 --- session.c Mon Jun 18 14:15:29 2001 *************** *** 93,98 **** --- 93,99 ---- void session_close(Session *s); void do_exec_pty(Session *s, const char *command); void do_exec_no_pty(Session *s, const char *command); + void do_exec(Session *s, const char *command); void do_login(Session *s, const char *command); void do_child(Session *s, const char *command); void do_motd(void); *************** *** 270,286 ****...

...2001, and he sent in a patch that moved the do_pam_session call into the do_login function in session.c. I can't find any discussion about why that patch did not get applied, but it hasn't, so I propose, instead of moving the do_pam_session call, to move the call to get_last_login_time into do_exec_pty and pass the resultant information to do_login. This has the unfortunate result of getting information that you may never use, but it seems that the portable release does have a few things in it explicit for one system or another, so this may be viable. The definition of do_login could be changed a...

FYI-- session.c fails from openSSH 2.9.9p2 with SunPro C compiler on Solaris 7, 8. The function do_pre_login had to be moved to before its use in do_exec_pty (a predeclaration would work). It does appear to work correctly, given the above fix. Still having the largefile problem (argh), so if anyone can help with /that/ ... -- Austin David -- Sr. Systems Architect Wink Communications Austin.David at Wink.com (510) 337-6334

...-3.1p1-mods/session.c - --- openssh-3.1p1/session.c Thu May 9 12:18:34 2002 +++ openssh-3.1p1-mods/session.c Thu May 9 12:20:03 2002 @@ -98,10 +98,10 @@ static void session_pty_cleanup(void *); void session_proctitle(Session *); int session_setup_x11fwd(Session *); - -void do_exec_pty(Session *, const char *); +void do_exec_pty(Session *, const char *, const char *realname); void do_exec_no_pty(Session *, const char *); - -void do_exec(Session *, const char *); - -void do_login(Session *, const char *); +void do_exec(Session *, const char *, const char *realname); +vo...

...em appears to be that do_pam_session is being called after we drop to the user's uid. Without privsep turned on, this all work, as we drop to the user's uid after do_pam_session. Specifically: with privsep on, do_setusercontext in privsep_postauth (sshd.c) is called before do_pam_session in do_exec_pty (session.c). Without privsep, we only drop root privs in do_child (session.c), which is after we do_exec_pty, since (obviously) the former code/call to do_setusercontext is unreached. A possible (does appear to work, though not properly tested) solution is to simply call do_pam_session in privsep_p...

...+379,11 @@ packet_integrity_check(plen, 0, type); } if (forced_command != NULL) { + saved_command = command; command = forced_command; debug("Forced command '%.500s'", forced_command); + } else { + saved_command = NULL; } if (have_pty) do_exec_pty(s, command, pw); @@ -1042,6 +1047,9 @@ env = xmalloc(envsize * sizeof(char *)); env[0] = NULL; + if (saved_command) { + child_set_env(&env, &envsize, "command", saved_command); + } if (!options.use_login) { /* Set basic environment. */ child_set_env(&env, &e...

do_pre_login() in session.c is used (in do_exec_pty()) before it's declared, which is causing some problems for me. please move it up a couple hundred lines in the file. patch included for 0807 snapshot. thanks, wendy % diff -u session.c.orig session.c.mod --- session.c.orig Tue Aug 7 13:11:51 2001 +++ session.c.mod Tue Aug 7...

...ssion_input_channel_req debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: calling session_shell_req debug1: calling packet_check_eom debug1: calling do_exec debug1: calling do_exec_pty setsid: Not owner debug1: Received SIGCHLD. debug1: parent+ debug1: parent++ ^rz192:~ # The "parent+" debug statements are in patch No 3. Index: auth.c =================================================================== RCS file: /usr/local/.cvs/auth/openssh/auth.c,v retrieving revision...

...this problem by the time I finally found this mailing list and noticed that a recent message from Matt Eagleson had supplied a potential patch. My version of the fix is fairly similar to Matt's, but I put the relocated record_login() call into its own function rather than putting it back into do_exec_pty(). The appended patch makes use of Matt's LOGIN_NEEDS_UTMPX autoconf changes, and has the added benefit that it doesn't call record_login() twice in the "UseLogin no" code path (which is a bug in Matt's patch). Another problem I noticed (that I haven't seen mentioned else...

http://bugzilla.mindrot.org/show_bug.cgi?id=637 Summary: ssh records that the user has logged out even though an sftp session is active Product: Portable OpenSSH Version: 3.6.1p2 Platform: All OS/Version: All Status: NEW Severity: security Priority: P1 Component: ssh AssignedTo:

...org/show_bug.cgi?id=423 ------- Additional Comments From djm at mindrot.org 2003-03-10 12:06 ------- The patch looks good, but the only thing that makes me wary is the use of signals for IPC. Would it not be possible to do the chauthtok call earlier? E.g. after the call to do_pam_session() in do_exec_pty()? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

...-- I am reopening this bug because I am still able to reproduce it on Solaris 10 with openssh 5.6p1. It seems to be caused by the same reason: do_pam_session updates the /var/adm/lastlog before record_login / store_lastlog_message is called. I don't understand why the fix doesn't work but do_exec_pty doesn't seem to be called before do_pam_session. -- Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

...-f /etc/sshd_config ef5b7488 poll (efffd160, 2, 64) ef5cd064 select (efffd170, ef6266cc, 11e8d0, ef6266d0, 11e8d4, 11) + 280 00034560 wait_until_can_do_something (effff24c, effff248, effff244, 64, 4, 1) + 2b8 00034d74 server_loop (fb000, 0, 104000, fb000, 104000, effff240) + 20c 00036c7c do_exec_pty (10bbcc, 11, 36634, fb400, 8a, 0) + 260 00036704 do_authenticated1 (0, 36400, fac00, 106800, ef623700, 36014) + 60c 00036074 do_authenticated (110fa8, efffefbc, d0710, 400, efffefc8, 0) + 80 0002d720 do_authentication (effff418, 3, fac00, cfc00, fb000, 10e400) + 174 0002c17c main (1eb4, f,...

...9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- session.c 2001/09/16 22:17:15 2.9.9.2 +++ session.c 2001/09/28 18:17:11 2.9.9.2.0.1 @@ -126,6 +126,9 @@ static void session_pty_cleanup(void *); void session_proctitle(Session *); int session_setup_x11fwd(Session *); void do_exec_pty(Session *, const char *); +#ifdef LOGIN_NEEDS_UTMPX +static void do_pre_login(Session *s); +#endif void do_exec_no_pty(Session *, const char *); void do_exec(Session *, const char *); void do_login(Session *, const char *); @@ -147,6 +150,7 @@ extern int debug_flag; extern u_int utmp_len; exte...

http://bugzilla.mindrot.org/show_bug.cgi?id=83 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|fork() fails when there are |PAM limits applied |PAM limits set |incorrectly ------- You are receiving this mail because: ------- You

...0 in ?? () #1 0x0003ccb4 in fatal_cleanup () at ../log.c:254 #2 0x00038988 in fatal (fmt=0xf0c00 "") at ../fatal.c:39 #3 0x00023400 in do_tty_change_password (pw=0x10e690) at ../auth-passwd.c:300 #4 0x00029884 in do_login (s=0x101b4c, command=0x0) at ../session.c:764 #5 0x00029518 in do_exec_pty (s=0x101b4c, command=0x0) at ../session.c:617 #6 0x000296c0 in do_exec (s=0x101b4c, command=0x0) at ../session.c:710 #7 0x0002b1b0 in session_shell_req (s=0x101b4c) at ../session.c:1729 #8 0x0002b358 in session_input_channel_req (c=0x110cd8, rtype=0x10f750 "shell") at ../session.c:...

...e.? Can anyone tell what is missing for my interactive session?? Ah, I have to back up a bit about what I did for the interactive session.? Since on windows, there is no concept of tty, instead of allocating a pty, I just created a sockpair to hook up the ptyfd and ttyfd when forking the child from do_exec_pty.? The ttyfd contains one of the socket of the socket pair, and the socket handle was passed? as the stdin/stdout/stderr of the windows cmd shell that is started by the child.? Could that be the reason?? Is the client always working on the raw mode?? Or it detected some setting being sent back from...