Date: Thu, 18 Oct 2001 20:33:21 -0400 From: Yarema <yds@dppl.com> To: Sam Varshavchik <mrsam@courier-mta.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: <1176920000.1003451601@volyn.dppl.net> In-Reply-To: <courier.3BCF5D10.00000C69@ny.email-scan.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Thursday, October 18, 2001 22:52:00 +0000 Sam Varshavchik
<mrsam@courier-mta.com> 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 <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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1176920000.1003451601>