From owner-freebsd-stable@FreeBSD.ORG Tue Nov 30 06:33:37 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4A9716A4CE for ; Tue, 30 Nov 2004 06:33:37 +0000 (GMT) Received: from wasley.bl.mmtr.or.jp (wasley.bl.mmtr.or.jp [210.228.173.142]) by mx1.FreeBSD.org (Postfix) with SMTP id BF9C743D31 for ; Tue, 30 Nov 2004 06:33:36 +0000 (GMT) (envelope-from rushani@bl.mmtr.or.jp) Received: (qmail 27060 invoked from network); 30 Nov 2004 15:33:35 +0900 Received: from unknown (HELO localhost) (202.229.142.170) by wasley.bl.mmtr.or.jp with SMTP; 30 Nov 2004 15:33:35 +0900 Date: Tue, 30 Nov 2004 15:32:27 +0900 (JST) Message-Id: <20041130.153227.30105543.rushani@bl.mmtr.or.jp> To: michaelnottebrock@gmx.net From: Hideyuki KURASHINA In-Reply-To: <200411300123.23822.michaelnottebrock@gmx.net> References: <200411300123.23822.michaelnottebrock@gmx.net> X-URL: http://www.rushani.jp/ X-PGP-Public-Key: http://www.rushani.jp/rushani.asc X-PGP-Fingerprint: A052 6F98 6146 6FE3 91E2 DA6B F2FA 2088 439A DC57 X-RC5-72-Stats: http://stats.distributed.net/participant/psummary.php?project_id=8&id=432320 X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org Subject: Re: symlinked $HOME/.login_conf ignored X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 06:33:37 -0000 Hi, >>> On Tue, 30 Nov 2004 01:23:23 +0100, Michael Nottebrock said: > I just discovered that .login_conf must not be symlinked in order to get > applied. Bug or feature? Just a feature. login_cap(3) says as follows, DESCRIPTION [...] ronment before the shell is invoked on login. Note that access to the /etc/login.conf and .login_conf files will only be performed subject to the security checks documented in _secure_path(3) for the uids 0 and pwd->pw_uid respectively. and you'll get the answer from _secure_path(3). -- rushani