From owner-freebsd-arch Sat Oct 26 19:59:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF23B37B404 for ; Sat, 26 Oct 2002 19:59:37 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5F0E43E42 for ; Sat, 26 Oct 2002 19:59:36 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g9R2x2Oo081861 for ; Sat, 26 Oct 2002 22:59:03 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 26 Oct 2002 22:59:02 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) In-Reply-To: <20021027021440.GB58312@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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