Date: Thu, 18 Oct 2001 10:02:25 -0400 From: Yarema <yds@dppl.com> To: Sam Varshavchik <mrsam@courier-mta.com>, courier-users@lists.sourceforge.net, ports@FreeBSD.org Cc: Neil Blakey-Milner <nbm@mithrandr.moria.org> Subject: Re: [courier-users] Re: Courier-MTA on FreeBSD Message-ID: <945820000.1003413745@volyn.dppl.net> In-Reply-To: <courier.3BCEC23C.0000781F@ny.email-scan.com> References: <782730000.1003396678@volyn.dppl.net> <courier.3BCEC23C.0000781F@ny.email-scan.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Thursday, October 18, 2001 11:51:24 +0000 Sam Varshavchik <mrsam@courier-mta.com> wrote: > Yarema writes: >> OK, what I've got so far is a completed port of sysconftool which >> probably belongs in the devel section of FreeBSD ports. Recent >> Courier-MTA builds depend on it even though the INSTALL docs say that >> tarballs shouldn't have that dependency -- only CVS versions should. >> No matter, having > > They don't. You do not need sysconftool to build out of a tarball. Well FWIW both courier-0.35.1 and courier-0.35.1.20011014 fail when building under FreeBSD's ports system without sysconftool installed. This does not mean that the tarball is at fault. It just means that the way FreeBSD bsd.port.mk's configure target is called breaks the tarball's dependency on it's included sysconftool or something to that effect. This is not a big deal. >> courier/rootcerts dependency on the OpenSSL tools/c_rehash. On FreeBSD >> it does exist in /usr/src/crypto/openssl/tools/c_rehash source tree but >> is not installed as part of the base system. I've got a workaround for >> this but a better alternative would be for courier to include the >> Makefile which comes with Apache+mod_ssl to do the same thing that >> OpenSSL's > > Use --without-rootcerts to avoid install the root SSL certs, which does > not require c_rehash. I know, but since what I'm doing will likely be a binary package in the future I'd like it to be as full featured as possible. Again, this hurdle I solved already. I still think installing a Makefile to do what c_rehash does would make it easier to update rootcerts *after* a binary package is installed without requiring c_rehash to be present on the system. >> Unless there's a reason that I don't know yet I believe it's a mistake >> to install binaries owned by user or group courier or daemon or bin >> unless the corresponding suid or sgid bit are also set for that binary. >> I believe all binaries should be owned by root:wheel except the ones >> that need a suid or sgid bit set to a different user. This provides an >> extra layer of protection to the binaries since most of the system runs >> as an unprivileged user which cannot modify files owned by root. > > That is incorrect. For most binaries it doesn't matter. But for many > binaries and files it does matter, since several binaries are by design > not executable by world, and only by group. make install does not > randomly choose the ownership and permission of every file. There is a > reason for why many files have their specific permissions and ownership. I understand there's a reason -- I'm not new to this. However for the files and binaries where it doesn't matter it would be preferable that they be installed as root:wheel or whatever the OS convention is. If for no other reason than just to be able to easily tell which files require to be owned by a particular user and which don't. >> As it is now if most of the courier processes run as uid courier and >> most of the binaries are owned by user courier what's to stop a >> compromised process from installing a back door to the system by >> modifying a binary owned by the same unprivileged user courier? > > If your system is compromised, you are fscked anyway. My philosophy is > to prevent the compromise in the first place, instead of accepting it as > a fact of life, and bending over backwards trying to mitigate the > damages. I recognized and like your philosophy. Though I would hardly call it 'bending over backwards' to install files owned by a more protected user if it doesn't matter who owns the file. >> On the plus side is that I'm already cleanly installing and deinstalling >> the package. I have a dialog configuration script like the one I >> adapted for postfix-current to select dependencies and options. And >> the package seems to conform to hier(7) at least as much as postfix >> does. >> >> Oh yeah.. just to be clear I'm working on FreeBSD 4.4-STABLE porting >> Courier -0.35.1. I started with courier-0.35.1.20011014 but ran into >> some libtool problems. > > Again - why are you messing around with libtool, or any dev tools if you > are building out of the tarball? You're doing this wrong. The tarball > has the correct configure script, has the correct Makefile.in, and > includes the autoconf/automake/libtool/sysconftool macros necessary to > build everything without requiring the dev tools to be installed. -- > Sam I am not messing around with libtool. I'm not even patching anything. I was merely reporting on my progress in creating a FreeBSD port to be comitted to their CVS and the problems I encountered along the way. It's premature to say I'm doing this wrong. The Makefile I wrote for this port looks much cleaner than any previous attempts people pointed me to. And as of now I can create a binary package which installs and deinstalls cleanly. The file ownership thing is a pet peev of mine but I can dael with that. The INSTALL macro issue is a problem though. I've worked around it. But the tarball Makefile.in and autoconf/automake/libtool/sysconftool generate: INSTALL = ../ in about a dozen resulting Makefiles and after everything builds correctly the install fails somewhere down the line. Once again I'm not applying any local patches nor am I messing around with any of the toolchain. I'm just following the FreeBSD Porter's Handbook to the letter if I can help it. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html Other than the INSTALL macro issue everything works as well as expected. I don't really expect a fix for this until I track down exactly why the macro fails. Cheers, -- Yarema To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?945820000.1003413745>