HELP! Is that possible "creating a user named root but acturally not the administrator root"

[Giorgos Keramidas]

On Thu, 11 Feb 2010 08:04:00 +0000, Matthew Seaman <m.seaman at black-earth.co.uk> wrote:
>On 11/02/2010 05:23, Giorgos Keramidas wrote:
>>On Thu, 11 Feb 2010 00:18:30 -0500, Robert Huff <roberthuff at rcn.com> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20100211/c1227fd6/attachment.pgp