From owner-freebsd-ports Thu Oct 18 17:33:46 2001 Delivered-To: freebsd-ports@freebsd.org Received: from sapas.dppl.net (sapas.dppl.com [216.182.10.231]) by hub.freebsd.org (Postfix) with ESMTP id 402F237B405 for ; Thu, 18 Oct 2001 17:33:29 -0700 (PDT) Received: from volyn.dppl.net (cc375212-a.union1.nj.home.com [24.253.222.7]) by sapas.dppl.net (Postfix) with ESMTP id 6CCB23E12; Thu, 18 Oct 2001 20:33:22 -0400 (EDT) Date: Thu, 18 Oct 2001 20:33:21 -0400 From: Yarema To: Sam Varshavchik Cc: courier-users@lists.sourceforge.net, ports@FreeBSD.org, Neil Blakey-Milner , Roland Schneider Subject: Re: Courier-MTA on FreeBSD Message-ID: <1176920000.1003451601@volyn.dppl.net> In-Reply-To: References: <782730000.1003396678@volyn.dppl.net> <945820000.1003413745@volyn.dppl.net> X-Mailer: Mulberry/2.1.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --On Thursday, October 18, 2001 22:52:00 +0000 Sam Varshavchik wrote: > Yarema writes: >> 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. > > Not everyone has a wheel group, so I can't specify it in my tarballs. > As I general rule of thumb: anything that I install in bindir or sbindir > that is group-executable, not a soft link, and does NOT have a setuid or > setgid bit can have its ownership adjusted. For soft links, follow the > soft link and look where it's pointing to. You're probably better off > doing this as a post-install fixup. Alternatively, after running make > install run make install-perms from the source directory, and look at the > permissions.dat file. The make install-perms target generates > permissions.dat which lists every file that gets installed, and what it's > permissions are. I wish I'd known about the install-perms target *before* I put together the pkg-plist file by hand. :) Oh, well.. thanks for the tip. What about files in sysconfdir, datadir and libexecdir? Do they follow the same rule of thumb? Do all the files in sysconfdir need to be installed as courier:courier? In your reply to Roland Schneider you say: > The alias account uses courier's uid/gid. > Solution: take steps to make sure that your system is not compromised > in the first place. But even good sysadmins make mistakes. This is precisely why qmail has a sperate account called alias. It's been a while since I ran any qmail boxen so I'll refer to Postfix docs in local(8) DELIVERY RIGHTS Deliveries to external files and external commands are made with the rights of the receiving user on whose behalf the delivery is made. In the absence of a user context, the local daemon uses the owner rights of the :include: file or alias database. When those files are owned by the superuser, delivery is made with the rights specified with the default_privs configuration parameter. FYI default_privs = nobody by default. compare what you said above and how postfix is documented with the documentation in courier's makealiases(8): NOTE: Unlike sendmail, Courier delivers as user "daemon" (group daemon) when delivering to programs or mailboxes. Perhaps the documentation is wrong and needs updating. But regardless I see this as a weakness in courier compared to qmail or Postfix and Exim. In the latter two this delivery rights are configurable and are not the same as the rights of the daemon processes or any of the configuration files. I would certainly prefer if all the config files and directories were owned by root rather than courier's uid/gid. Perhaps emulating postfix behavior would be a good idea although there seems to be an anti-nobody movement on FreeBSD at the moment .. but that's a different topic. >> 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 = ../ > > This is usually the result of the INSTALL environment variable being set > before running configure. Unset INSTALL before running configure. -- No can do. INSTALL="/usr/bin/install -c -o ${BINOWN} -g ${BINGRP}" is defined in bsd.port.mk for the do-configure target. It works fine for the latest Courier-IMAP, maildrop and SqWebMail ports. Yes, I could redefine the do-configure target for the courier port, but I don't think I should have to. Upon further investigation I found a pattern to the INSTALL macro issue. After a build in the top src directory grep '^INSTALL = ../' Makefile */Makefile */*/Makefile */*/*/Makefile produces: courier/doc/Makefile:INSTALL = ../ courier/filters/Makefile:INSTALL = ../ courier/filters/libfilter/Makefile:INSTALL = ../ courier/filters/perlfilter/Makefile:INSTALL = ../ courier/libs/Makefile:INSTALL = ../ courier/module.dsn/Makefile:INSTALL = ../ `test ! -w /etc || echo -o daemon -g daemon` courier/module.esmtp/Makefile:INSTALL = ../ `test ! -w /etc || echo -o daemon -g daemon` courier/module.local/Makefile:INSTALL = ../ `test ! -w /etc || echo -o daemon -g daemon` courier/module.uucp/Makefile:INSTALL = ../ `test ! -w /etc || echo -o daemon -g daemon` courier/webadmin/Makefile:INSTALL = ../ webmail/html/Makefile:INSTALL = ../ webmail/html/en-us/Makefile:INSTALL = ../ webmail/html/en/Makefile:INSTALL = ../ webmail/images/Makefile:INSTALL = ../ note that only the Makefiles located two or more levels below the top src directory contain the bogus macros. For all directories more than one level down configure output shows the following: loading cache ../.././config.cache checking for a BSD compatible install... ../ I'm not doing anything that different than what the SqWebMail port does. And this doesn't happen there. Thoughts? -- Yarema To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message