Date: Sat, 26 Oct 2002 22:59:02 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: arch@FreeBSD.org Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Message-ID: <Pine.NEB.3.96L.1021026223114.73222A-100000@fledge.watson.org> In-Reply-To: <20021027021440.GB58312@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 26 Oct 2002, David O'Brien wrote:
> On Thu, Oct 24, 2002 at 12:17:09PM -0400, Robert Watson wrote:
> > Given that lukemftpd is highly feature incomplete with regards to the
> > default ftpd, I'd like to propose at least the following:
>
> What "default" ftpd? We don't have one anymore. I consider it a HUGE
> feature that lukemftpd doesn't do PAM. Like the new "standards"
> headers, PAM has done nothing for me over what I had in pre-PAM'ized
> FreeBSD, but cause great pain. Yet another promiss of something the
> better and easier that has not turned out to be the case.
You seem to have ignored the remainder of my questions, including whether
or not you plan to add support for login.conf to lukemftpd, which is
required to support:
- Process resource limits
- Per-class login requirements, including per-class nologin file,
per-class ignorenologin, per-class requirehome
- Per-class umask
- Per-class motd, copyright
- MAC
> Anyway, please do not do anything to lukemftpd until I return.
My e-mail was a solicitation for advice on where we should take this.
This is something we need to address before the release. Thus far, I've
added the warning notice to inetd.conf to warn users away from it if their
requirements include any of these standard and widely documented FreeBSD
features.
> > (1) All references to lukemftpd as "the ftpd" be corrected to indicate
> > lukemftpd is not the default. Most of these are leaked references
> > from lukemftpd man pages that were not updated in the import.
>
> We typically don't rewrite contrib'ed vendor branch code. On some of my
> systems lukemftp is THE ftpd, so they do apply.
If we choose to ship two ftp daemons on the same system, we need to
carefully distinguish them. Since we install lukemftpd as lukemftpd,
correctly documenting that is important. For example, if it's called
lukemftpd, it should not be refered to as "ftpd" in the man pages, since
"ftpd" is ftpd(8). The man page cross references are incorrect.
In addition, the contributed daemons in the system, such as sendmail,
provide native support for our login.conf management via
setlogincontext()/setusercontext(). I'm all for bringing in cool new
daemons, but if they don't support expected system features, such as
centralized user classes, resource limits, authentication, logging and
accounting, etc. If they do not, they need to be carefully documented as
such. If we introduce new daemons, it's important that they be correctly
documented, and that if we have two seperate sets of daemons that support
largely identical services, they need to be carefully distinguished. For
example, daemon configuration paths should be correct, cross references
should be correct, etc.
> > (2) Remove reference to lukemftpd in inetd.conf: it looks a little silly
> > to have a warning there, and the only purpose of listing something in
> > inetd.conf is if you plan to have it be the one users turn on.
>
> We do intend for people to turn it on. It should stay where it is.
>
> > (4) The release notes indicating lukemftpd has been imported should be
> > updated to indicate it is not the "default" and that it is feature
> > incomplete.
>
> It is not incomplete -- it has a fine set of functionalty. In fact it
> has larger functionality in that it is imperlious to PAM f*&king over
It is feature incomplete because it does not support:
(1) FreeBSD's standard authentication mechanisms, including OPIE
(2) FreeBSD's standard resource limits
(3) FreeBSD's standard user login limits
If the daemon remains in the tree, these facts must be carefully and
clearly documented, since there is *great* potential for foot-shooting.
All of the following scenarios are now possible:
(1) Administrators rely on OPIE authentication to permit users to log in
securely, but switching to lukemftpd does not permit users to log in
as lukemftpd does not support OPIE, unlike every other
authenticating daemon in the system.
Administrators rely on PAM authentication modules to authenticate
users using pam_ldap for distributed account management, but switching
to lukemftpd does not allow users to log in.
Administrators rely on a PAM configuration to specify the desired
authentication order, trying local authentication first, then trying
KerberosIV. Switching to lukemftpd requires use of the hard-coded
authentication order in the source code.
(2) Administrators rely on per-class resource limits to prevent the undue
consumption of system memory, CPU, or file size. As a result of
enabling lukemftpd, these limits are no longer enforced.
(3) Administrators rely on per-class nologin in login.conf, and because
they enabled lukemftpd, these restrictions are no longer enforced.
There seem to be two basic classes of problems here:
(a) lukemftpd doesn't use setlogincontext(), unlike every other base
system daemon or tool managing user contexts (telnetd, login,
sendmail, cron, ...). setlogincontext() provides centralized
management of process credential state, resource limits, login limits,
etc.
(b) lukemftpd does not support the use of PAM, unlike every other
base system authenticating daemon. While most of the base system
tools support disabling PAM, they ship with PAM by default, providing
access to OPIE and many other authentication types that are widely
used.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021026223114.73222A-100000>