From owner-freebsd-questions@FreeBSD.ORG Thu May 12 08:00:17 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D381116A4CE for ; Thu, 12 May 2005 08:00:17 +0000 (GMT) Received: from proxy.ddcom.co.jp (proxy.ddcom.co.jp [211.121.191.163]) by mx1.FreeBSD.org (Postfix) with SMTP id D90FE43D58 for ; Thu, 12 May 2005 08:00:16 +0000 (GMT) (envelope-from rees@ddcom.co.jp) Received: (qmail 10099 invoked by alias); 12 May 2005 08:11:46 -0000 Received: from unknown (HELO matthew) (10.10.10.11) by mail.ddcom.local with SMTP; 12 May 2005 08:11:46 -0000 Date: Thu, 12 May 2005 17:00:15 +0900 From: Joel To: freebsd-questions@freebsd.org In-Reply-To: <20050511170133.GD10213@asu.edu> References: <20050511170133.GD10213@asu.edu> Message-Id: <20050512161516.478C.REES@ddcom.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.06 Subject: Re: best practices for administration X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 08:00:17 -0000 > The nexus of my query lies in my attempt to have our central IT folks > issue additional identities for users to have when administering the > systems versus doing productivity work on them. I'd like to understand > what is done generally when granting users permissions to do things on > the operating system that imply 'administration', ie installing > software, adding printers, modifying system scripts, etc. There are > some here who think that putting standard user ID's into > administrative 'groups' is sufficient for granting such priveledges. Users will always resist anything that will cause them to type in another password to get their job done. Probably you want to mix approaches a bit. Certain tasks will warrant a separate login, in part to sandbag against trojans and other malware. If you do set up such accounts, make sure browsing-type accounts are not allowed to sudo to admin-type accounts, and establish a policy of not using su from the browsing accounts. (Helps keep any keyloggers from getting at abuseable passwords.) I'd even suggest not allowing login from the browsing accounts, but I haven't yet figured out how to effectively sudo -u joe2 webbrowser . Heh. One difficulty is getting users into the habit of knowning when to share files with themselves. -- Joel Rees digitcom, inc. 株式会社デジコム Kobe, Japan +81-78-672-8800 ** **