similar to: [Bug 423] New: Workaround for pw change in privsep mode (3.5.p1)

http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From michael_steffens at hp.com 2002-11-02 02:40 ------- Created an attachment (id=162) --> (http://bugzilla.mindrot.org/attachment.cgi?id=162&action=view) Patch: Workaround for pw change in privsep mode (3.5.p1) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are

http://bugzilla.mindrot.org/show_bug.cgi?id=423 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |627 nThis| | Status|NEW |ASSIGNED ------- Additional

http://bugzilla.mindrot.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

http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From stevesk at pobox.com 2003-01-02 11:52 ------- regarding log() clash, shouldn't the HP libsec log() be static or renamed or ? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=423 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |serg at bspb.ru ------- Additional Comments From dtucker at zip.com.au 2003-05-13 09:55 ------- *** Bug 562 has been marked as a

http://bugzilla.mindrot.org/show_bug.cgi?id=419 Summary: HP-UX PAM problems with 3.5p1 Product: Portable OpenSSH Version: -current Platform: HPPA OS/Version: HP-UX Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy:

http://bugzilla.mindrot.org/show_bug.cgi?id=419 ------- Additional Comments From michael_steffens at hp.com 2002-10-21 17:54 ------- Created an attachment (id=157) --> (http://bugzilla.mindrot.org/attachment.cgi?id=157&action=view) Patches for making privsep run with HP-UX trusted mode amd avoid credentials deletion errors Sorry, being new to bugzilla I didn't know that

Hi All. Attached is a patch that implements password expiry with PAM and privsep. It works by passing a descriptor to the tty to the monitor, which sets up a child with that tty as stdin/stdout/stderr, then runs chauthtok(). No setuid helpers. I used some parts of Michael Steffens' patch (bugid #423) to make it work on HP-UX. It's still rough but it works. Tested on Solaris 8 and

Hello All. Attached is an update to my previous patch to make do_pam_chauthtok and privsep play nicely together. First, a question: does anybody care about these or the password expiration patches? Anyway, the "PRIVSEP(do_pam_hauthtok())" has been moved to just after the pty has been allocated but before it's made the controlling tty. This allows the child running chauthtok to

I haven't recompiled since 3.5p1. I compile --with-privsep-user=nobody * I observe that none of my processes is uid "nobody". In addition, previously I had to disable privsep on either AIX or OSF1 (I forget which), this time it just worked. I was thinking it was because Progress Had Been Made. Now, observing so many root processes, I think it's because privsep is not actually

Without giving a solution, I want to mention the following problem: Not only changing expired passwords when privilege separation is enabled in combination with PAM is not working (although the current patches seem to solve this one). Also some PAM session modules do not work the way they are supposed to. For instance, the pam_lastlog module. This module gets and updates the last successful

http://bugzilla.mindrot.org/show_bug.cgi?id=808 Summary: segfault if not using pam/keyboard-interactive mech and password's expired Product: Portable OpenSSH Version: 3.8p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: PAM support

Hi. If sshd is configured to use PAM and UsePrivilegeSeparation=no or you are logging is as root, any messages returned by PAM session modules are not displayed to the user. (Even when the config file has privsep=yes, logging in as root disables privsep anyway since there's no point, so it behaves the same way as privsep=no). I think I've figured out why: when privsep=no,

A few things to keep in mind: - kbd-int should call pam_authenticate(), acct_mgmt(), chauthtok(), if required, setcred(PAM_ESTABLISH_CRED) and open_session() ALL during kbd-int so that modules in each of those PAM stacks can prompt the user (pam_open_session(), for example, may prompt a user with an informational message akin to the last login message) - all userauth methods should

Hi, This is included in the release now; any feedback? Privilege separation, or privsep, is method in OpenSSH by which operations that require root privilege are performed by a separate privileged monitor process. Its purpose is to prevent privilege escalation by containing corruption to an unprivileged process. More information is available at:

http://bugzilla.mindrot.org/show_bug.cgi?id=329 Summary: gmake install prefix=... does not work with the privsep-path Product: Portable OpenSSH Version: -current Platform: MIPS OS/Version: IRIX Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo:

http://bugzilla.mindrot.org/show_bug.cgi?id=354 Summary: sshd with privsep doesn't do pam session setup properly Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org

Hello, We use USE_POSIX_THREADS in our HP-UX build of OpenSSH. When we connect a non-root user with PAM [pam-kerberos] then I get the following error. debug3: PAM: opening session debug1: PAM: reinitializing credentials PAM: pam_setcred(): Failure setting user credentials This is particularly for non-root users with PrivSep YES. When I connect to a root user with PrivSep YES or to a non-root

Hi all. I have a question regarding privsep. Firstly, the following is my understanding of what happens when privsep is enabled: The sshd daemon is running as root listing on 22(a). When a connection is accepted, a child is forked to handle the connection, this child becomes the monitor(b). The monitor forks the pre-auth privsep slave(c), which sheds it privs and hides in its chroot jail.

http://bugzilla.mindrot.org/show_bug.cgi?id=270 Summary: PrivSep breaks sshd on AIX for non-root users Product: Portable OpenSSH Version: -current Platform: PPC OS/Version: AIX Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: