Exactly how much impact does the root user have on the system? When I say that, I mean, how often is something hardcoded into a program that refers to the root user?

The reason I ask is this:
While reading through chapter 6 in LFS5 about creating the passwd and group files, I began to wonder if it was possible to create the root user as some other username than "root". I could simply name the user who is uid:0 groupid:0 to something else.

Possible pros for this:
It would be harder for a person to get root access to the system without knowing the root username. It forces a person to need both the username and the password, instead of just the root password.

Possible cons:
My worry is that some program is going to give access rights to something to the user "root" that will not exist. A possible solution would be to create a restricted user named "root", which maybe creates a tease to someone who finds the password to root, but doesn't really have root access over anything. Additionally, this root would own anything that a program gives ownership to thinking it is the true root user.

I guess it all comes back to my original question: How many programs actually contain code that refers to the root user as the name "root"?

I guess the major major question is, will a system function with the 0:0 user as something other than "root"?

If I'm not mistaken most well coded programs will utilze the uids and guids rather than hard code the root string. But im not an expert coder.

That's what I would think too, but I keep thinking that I read in the LFS5 book that a well coded program uses the name. I can understand using the uid for root to consider uid 0 as the root user all the time, but when you use the uid for any other users (and correct me if I am wrong) when a user is deleted and another is added, that user could have the same uid as a previous user, which would be bad if ownership rights are to a user id instead of a name. But I am a novice to linux at best, so I could be way out in left field.

One reason not to do this:

Security thru obscurity doesn't always work!

But isn't that the basis for forming a strong password? Making it obscure? I think obscurity is a basic form of security. Of course it isn't enough on it's own. It's just a basic form.

If you're going to make an obscure password, why not make an obscure 0:0 login account?

The reason that this is often fairly fruitless is that the most common attack vectors do not require a user to know the account name of uid(0). Most compromises happen through exploiting processes that give the user uid(0), e.g. a buffer overflow in a daemon that is running as uid(0). Actual attacks based upon entering the root username and password are fairly rare. This is because, unless they already have root and can view the hash and salt in the shadow file, the user would have to guess a random password that will have many permutations. Due to constraints that non-local access would place on this process, I would assume that most attacks of this type are local attacks - at which point catting the passwd would reveal the root username anyway.

As for the obscurity notion, yes a password is security through obscurity - this is why it has the obvious weakness that anyone can type it. However, it is one of the few instants that really add a lot of weight from obscure measures. The idea is to replace security through obscurity, with systems that are so secure the user can know all of the implementation details and still not break it. Security through obscurity works on a user no knowing a piece of information, but the assumption that the user can not find or guess this information is usually flawed.