From owner-freebsd-questions@FreeBSD.ORG Thu Feb 11 19:16:06 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8287B1065672 for ; Thu, 11 Feb 2010 19:16:06 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id EAB138FC15 for ; Thu, 11 Feb 2010 19:16:05 +0000 (UTC) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id B59FFEB4912; Thu, 11 Feb 2010 21:16:04 +0200 (EET) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id A4200160CD5; Thu, 11 Feb 2010 21:16:04 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea4FsC3ouh24; Thu, 11 Feb 2010 21:16:04 +0200 (EET) Received: from kobe.laptop (ppp-94-64-211-38.home.otenet.gr [94.64.211.38]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 53826160C75; Thu, 11 Feb 2010 21:16:04 +0200 (EET) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.4/8.14.4) with ESMTP id o1BJG3Be038373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 21:16:03 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.4/8.14.4/Submit) id o1BJG2RH038368; Thu, 11 Feb 2010 21:16:02 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Matthew Seaman References: <5ffa459b1002102005i6b03c6fcqc1d4a11f590164d4@mail.gmail.com> <19315.37670.468383.119569@jerusalem.litteratus.org> <874olocpmc.fsf@kobe.laptop> <4B73B9F0.1020105@black-earth.co.uk> Date: Thu, 11 Feb 2010 21:16:01 +0200 In-Reply-To: <4B73B9F0.1020105@black-earth.co.uk> (Matthew Seaman's message of "Thu, 11 Feb 2010 08:04:00 +0000") Message-ID: <87hbpntwge.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: Lin Taosheng , Robert Huff , freebsd-questions@freebsd.org Subject: Re: HELP! Is that possible "creating a user named root but acturally not the administrator root" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 19:16:06 -0000 --=-=-= On Thu, 11 Feb 2010 08:04:00 +0000, Matthew Seaman wrote: >On 11/02/2010 05:23, Giorgos Keramidas wrote: >>On Thu, 11 Feb 2010 00:18:30 -0500, Robert Huff wrote: >>>Lin Taosheng writes: >>>> Is that possible to implementated? >>> >>> For most purposes, what's important is not the account name, >>> but the User II. "Root" is special because it has UID 0. You can, >>> create other accounts with UIS 0 ... but it's usually a Very Bad >>> Idea. >>> >>> As far as I know, there's no reason you can't rename the "root" >>> account and have a non UID 0 account with that name. On the other >>> hand, if you're asking this question there may be a better way to >>> accomplish your objective: would you care to share? >> >> The kernel doesn't really care what your user *name* is. See for >> example the 'toor user in '/etc/master.passwd'. > > On the other hand, lots of software expects the superuser account to > be called 'root' because that what it always has been ever since > Thompson and Ritchie et al. first created Unix. Changing the name of > the superuser account, and making root into an unprivileged user will > cause you much wailing and gnashing of teeth. It doesn't really buy > you much in terms of improved security in any case. Far better to > concentrate on making it impossible for the existing root account to > be compromised. This is a good point. One can argue that the specific applications are those that are broken if they do not use a tunable option to switch the name of the 'privileged user'. But that doesn't negate the fact that precisely *this* type of applications exists out there and will break. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkt0V3EACgkQ1g+UGjGGA7bshwCdEXnOkpPSGV0KbIeKzkwvNF3q 3fsAnjt9tW6rj1+aZ2iHM6YUF1ATDzdm =41a8 -----END PGP SIGNATURE----- --=-=-=--