similar to: Tru64 privsep patch testing

Hi Toni, I'm sorry, I haven't had much time to work on this today. When I run sshd (from the patched snapshot) in a debugger, with a breakpoint early in setup_sia(), this is what I find after connecting with a client: (1) There are two sshd processes. One is running as root, and the other as the user I logged with using the client. The root process is the one in the debugger,

What do we loose by not having post-auth privsep? What code is executed between authorization and actual setting of the effective uid? On Tue, 3 Sep 2002, Chris Adams wrote: > Once upon a time, Toni L. Harbaugh-Blackford <harbaugh at nciaxp.ncifcrf.gov> said: > > It appears that the integration of the sia session setup will either > > have to be rethought or abandoned

Hi- Since the tru64 patch was designed for -current, I thought I would try to build it with a recent snapshot before backporting to 3.4p1. So I downloaded openssh-SNAP-20020826.tar.gz frpm the portable snapshots, but it does not contain the 'configure' script. I tried copying the 'configure' from 3.4p1, but that does not create a Makefile from the Makefile.in. Where are the

Hi- Under privsep, I experimented with moving the session_setup_sia() out of do_child() and into do_setusercontext(), which is where the uids/gids are set to the final execution user. The call is made with a NULL tty, and this is functional provided that any later pty allocation uses grantpty() to set the device permissions. Logging in with this method shows that a utmp entry does get made for

Hi- Unfortunately, I just found out about the patch that was available for tru64 privsep. I was entirely unaware that there was a lack of support. Will the patch be considered for approval if it is applied to 3.4p1, or does it have to be done against -current? The reason I'm asking is that I have 3.4p1 working as is, so I know if I have a problem it is likely related to the patch and not

Hi- I applied the privsep patch to Tru64 5.1A openssh 3.4p1 and it *almost* works. I get in from the client side and xauth is run, but in the meantime the server side disconnects. Running sshd in debug mode level 3 gives the following output: . . . debug1: session_input_channel_req: session 0 req shell debug1: fd 5 setting TCP_NODELAY debug1: channel 0: rfd 13

As I understand it, the idea behind privsep is to prevent malicious data from the client-side of a connection corrupting a server-side process running as root. To achieve that, it is important that post-auth privilege separation happen, ie, that the sshd process change uid to the (authenticated) user. But it is also true that this very same process can perform root-level work without risk of being

Ok.. I need wider testing for this. I'm getting reports back it works mostly. 'ssh site ls' fails, but they can login with Privsep enbled. Can I get those who are using Tru64 or OSF/1 that have SIA enabled to test? This should apple to either -cvs or the current snapshot (I would perfer not to use 3.4p1 due to bugs). I'm going on a trip next week and will be around very spotty

I have tried this with openssh-2.5.2p2 and openssh-SNAP-20010501. I have noticed that with a .hushlogin file in my home directory I still get messages. With the .hushlogin file I get these messages: Last successful login for ricardo: Tue May 1 08:06:00 2001 from blah.mnsu.edu Last unsuccessful login for ricardo: Tue May 1 08:05:21 2001 from blah.mnsu.edu Without the .hushlogin file I get

Hi- I built openssh-3.0p1 on a Tru64 4.0G without any problem. The system uses enhanced security, so the sia_* routines are used by sshd. Unfortunately, password authentication fails because sia_ses_authent() returns 0 in auth-sia.c. The thing is, the password is CORRECT; I verified this by inserting debugging statements before the call to sia_ses_authent(). The call to sia_ses_init()

Tru64 patch will not make it into 3.5 (this is final) due to lack of willing people to test. I have given the Tru64/osf1 community almost a month to test it. And *ONE* person came forward to give me verification. And don't give me shit about "I don't have time." The person who tested it was LEAVING his employer with Tru64. He found time. IT IS YOUR GAWD DAMN PLATFORM. IF

Either this never made it to the list or no one cares about Tru64. This is the last time I'll send this patch to the list. If no one steps up and finishes it or provides me with enough information to fix any remaining bugs (one being complaint that 'ssh site cmd' does not work right). If there is no activity on this for a week. I'll post it to bugzilla and will ignore any

Dear openssh-unix-dev; I recently downloaded the tarball openssh-3.4p1 and built it for my Tru64 Unix ( OSF/1 ) 5.1a system. My configure statement is: ./configure --prefix=/usr/local/security/tools/openssh-3.4p1 \ --exec-prefix=/usr/local/security/tools/openssh-3.4p1 \ -with-ssl-dir=/usr/local/security/tools/openssl-0.9.6g \ -with-zlib-dir=/usr/local/compress/tools/zlib-1.1.3 \

http://bugzilla.mindrot.org/show_bug.cgi?id=429 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE Summary|SSH 3.4p1 problems on Tru64 |SSH 3.4p1 problems

Hi, I've been experiencing intermittent filesystem corruption on a Compaq Armada M700 laptop w/ IBM Travelstar 30GB drives (both the 40GN and 30GN models). This happens mostly under RH 7.2, w/ ext3 filesystems, but I think it's also happened under win98. All seems fine until power-down, power-up, and boot, where the corruption is discovered. Searching these archives, I found that there

I am trying to compile sshd 3.8p1 on Tru64 UNIX V4.0F Patch Level 7. Previously I've compiled the entire 3.6.1p2 distribution with no problems. The problem seems to occur when linking sshd. The linker is unable to find xcrypt and shadow_pw functions (openbsd-compat/*.c). The libopenbsd-compat seems to have built without errors. I configure as follows: CC=cc CFLAGS=-O LDFLAGS=-non_shared

About a year ago I outlined a scheme for arranging chowning of the tty end of ptys without needing root privileges. Since then, I haven''t had time to actually implement it. I was thinking about the problem again today, and, having learned a bit about sessions and controlling ttys and stuff, was able to come up with a simpler mechanism. First, observe that the POSIX session mechanism, if

http://bugzilla.mindrot.org/show_bug.cgi?id=429 Summary: SSH 3.4p1 problems on Tru64 V4.0D & Tru64 V4.0F Product: Portable OpenSSH Version: 3.4p1 Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org

A patch for a few more hiccups and trivialities in kinit.c: * The check_path() calls check for "/root" and "/old_root" - I believe that should be "/root" and "/root/old_root". * chdir("/") is recommended after pivot_root() * init_argv[0] isn't set properly to the basename pointed to by char *s - this fix also eliminates six lines of

Well, after digging around and thinking some more, I'm giving up on the idea of preallocating a TTY to get post-auth privsep working on Tru64. I don't think it will work, because just allocating a TTY doesn't fix the problem - there's no valid way to tie that TTY back to the client process (because it hasn't requested a TTY yet and may not ever do so). The problem is that the