Date: Fri, 19 Oct 2001 01:31:12 GMT From: "Sam Varshavchik" <mrsam@courier-mta.com> To: Yarema <yds@dppl.com> Cc: courier-users@lists.sourceforge.net, ports@FreeBSD.org, Neil Blakey-Milner <nbm@mithrandr.moria.org>, Roland Schneider <list-courier@serv.ch> Subject: Re: Courier-MTA on FreeBSD Message-ID: <courier.3BCF8261.00001754@ny.email-scan.com> In-Reply-To: <1176920000.1003451601@volyn.dppl.net> References: <782730000.1003396678@volyn.dppl.net> <courier.3BCEC23C.0000781F@ny.email-scan.com> <945820000.1003413745@volyn.dppl.net> <courier.3BCF5D10.00000C69@ny.email-scan.com> <1176920000.1003451601@volyn.dppl.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Yarema writes:
> 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?
Many files in sysconfdir do not have world read permissions, in which case
their ownership MUST be preserved.
For all other directories the same rule of thumb: if it's an executable
file, its ownership doesn't matter if its world-executable, and the
equivalent for non-executable files.
> In your reply to Roland Schneider <list-courier@serv.ch> 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.
In that man page, user/group 'daemon' value is inserted by the configure
script, indicating that you've built Courier to use uid/gid daemon/daemon,
instead of courier/courier.
Were you to create uid/gid 'courier' prior to running the configure script,
the man page will read user "courier" (group courier) in this place.
>>> 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?
Makefile is generated from Makefile.in, which reads INSTALL = @INSTALL@, so
it comes from the environment.
--
Sam
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?courier.3BCF8261.00001754>