Hi,
I've seen a few patches related to the PrivSep works. As far as I can
see, it seems to work by using a shared memory segment to communicate.
I just want to point out that there are some unix systems that do not
have mmap() (SCO, older SVR3 systems) or that might have problems with
anonymous shared mmap() (don't have an examples, but e.g. the INN docs
are full of warnings concerning mmap()).
So I want to ask you to make the PrivSep stuff compile-time configurable,
to enable building on "legacy" platforms.
gert
PS: my SCO 3 fix for the suid problem seems to have been lost, I'll
resubmit via bugzilla.
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert at
greenie.muc.de
fax: +49-89-35655025 gert.doering at
physik.tu-muenchen.de
On Tue, Apr 02, 2002 at 01:00:04PM +0200, Gert Doering wrote:> I just want to point out that there are some unix systems that do not > have mmap() (SCO, older SVR3 systems) or that might have problems with > anonymous shared mmap() (don't have an examples, but e.g. the INN docs > are full of warnings concerning mmap()).those systems could try to use SYSV SHM instead of mmap(). I think Engelschall has something doing this (perhaps mm-1.1.x.tar.gz).
On Tue, 2 Apr 2002, Gert Doering wrote: :I've seen a few patches related to the PrivSep works. As far as I can :see, it seems to work by using a shared memory segment to communicate. : :I just want to point out that there are some unix systems that do not :have mmap() (SCO, older SVR3 systems) or that might have problems with :anonymous shared mmap() (don't have an examples, but e.g. the INN docs :are full of warnings concerning mmap()). : :So I want to ask you to make the PrivSep stuff compile-time configurable, :to enable building on "legacy" platforms. yes, what we want in the end is that ./configure;make will compile on the current platforms and work as it does today. privsep is by default off. the strategy i've taken is to get it working on portable platforms that i'm using (currently solaris 8 and hp-ux 11). now i'm thinking about how to support PAM. we currently support access rights and ancillary data fd passing. we should probably add I_SEND/RECVFD support, but i haven't seen anyone ask yet. same for shm support vs. mmap(). for platforms that cannot be supported, i think we will just fatal() on a required non-supported function if someone enables privsep. i think we should still handle preauth separation without fd passing support, but i haven't tested that.
i second this. I currently cannot get the current snapshot to compile. Crays do not have mmap and don't support shared memory. compile-time configuration would be a name-your-own-deity-send. wendy Gert Doering wrote:> > Hi, > > I've seen a few patches related to the PrivSep works. As far as I can > see, it seems to work by using a shared memory segment to communicate. > > I just want to point out that there are some unix systems that do not > have mmap() (SCO, older SVR3 systems) or that might have problems with > anonymous shared mmap() (don't have an examples, but e.g. the INN docs > are full of warnings concerning mmap()). > > So I want to ask you to make the PrivSep stuff compile-time configurable, > to enable building on "legacy" platforms. > > gert > > PS: my SCO 3 fix for the suid problem seems to have been lost, I'll > resubmit via bugzilla. > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany gert at greenie.muc.de > fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev-- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154