root=UID=0 Re: What microsoft has to say about XP

Nifty Hat Mitch mitch48 at sbcglobal.net
Wed Jan 19 19:09:44 UTC 2005


On Wed, Jan 19, 2005 at 01:13:40PM +0000, Paul Howarth wrote:
> Jeff Vian wrote:
> >On Tue, 2005-01-18 at 15:05 -0800, Nifty Hat Mitch wrote:
> >>Spot on.
> >>Renaming 'root' is full of pitfalls.
> >>Software commonly installs files symbolically root:root not 0:0.
> >>Scripts...
> >>   /etc/init.d/identd:       chown root:root /etc/identd.key
> >>Dozens and dozens of places.....  
> >>
> >
> >Sorry Mitch, your interpretation of this is not correct.
> 
> If root isn't UID 0 in /etc/passwd (or wherever the user data is held), 
> how is Mitch's example of "chown root:root /etc/identd.key" going to work?

I just picked an example of something that needs to be changed from my
system.

> Answer: it isn't. Error message "no such user".

Yep.
Of worse if root is not UID=0 then the file will have the wrong
permissions and functional ownership.

The reality is that UID=0 is special and that there is a
long standing history that maps root to UID=0.

It is true that the internals of the system only works with numeric
values but like IP addresses the mapping needs to have a sane and
systematic structure to it.  Root could be changed to anything
in the passwd file but the list of things that break because 
we comonly use the symbolic name "root" is long.

Tools and _users_ know the function and capabilities of various
accounts.  Changing them has sweeping implications.  Yes, It is
possible for one system manager to sweep through his system and change
root to administrator (for example) or BobXYZZ.  However from that
point on that administrator must screen and update all new software
packages in ways that do the right thing.

Note, Any user that has an account on the local machine can look for
:0: in the passwd file.  This means that the 'secret' account name
will be known by a set of users and the more that know the secret the
less secret it is.

We must include, Makedev, /dev, /proc, debuggers, NFS, SMB, 

Of interest various role transitions that SELinux can manage can well
constrain root.  These legal transitions can be made invisible to even
local accounts.  Perhaps to the point that nothing interesting can be
done by a login as root.  The interesting newrole transitions might
only be available from a role that some inocuous user account not root
has.

As I indicated to the OP.... try it on a test box.
This is a rich topic, worthy of discussion.

Here are some additional 'symbolic' references to UID=0
that need fixing if one wants to do this.

   /etc/security/console.apps/authconfig:USER=root
   /etc/security/console.apps/up2date-config:USER=root
   /etc/security/console.apps/dateconfig:USER=root  
   /usr/sbin/pwmconfig:                    chown root.root $X
   /lib/modules/*...*/arch/*/Kconfig
   ..../xdm/TakeConsole:chown root /dev/console
   ..../xserver/SecurityPolicy
   /etc/sysconfig/rhn/up2date:adminAddress=root at localhost
   /etc/sysconfig/arpwatch:OPTIONS="-u pcap -e root -s 'root (Arpwatch)'"
   /etc/group
   /etc/xinetd.d/*
   /etc/rc.d/rc.sysinit:        /usr/bin/passwd root
   /etc/hotplug/dasd.agent
   /etc/rc.d/rc.sysinit:chown root:root /tmp/.ICE-unix
   /etc/makedev.d/00macros
   /etc/logrotate.d/*
   /etc/security/console.apps/system-switch-mail:USER=root
   /etc/security/console.apps/authconfig:USER=root
   /etc/security/console.apps/*
   /etc/crontab:MAILTO=root
   /etc/crontab:01 * * * * root run-parts /etc/cron.hourly
   --ok I give up.... too many places.

-- 
	T o m  M i t c h e l l 
	spam unwanted email.
	SPAM, good eats, and a trademark of  Hormel Foods.




More information about the fedora-list mailing list