[Tyre MacAdmin]

Is it possible to change your root userid username to something besides "root" I was hoping to change it so it's a little harder to crack the root account...

[Arkham_c]

By default the root account is not even enabled. You don't have to worry about it being cracked in that case. If it doesn't allow logins, you're safe from direct logins as root.

[sandsl]

Possible but not advisable - changing it will have no effect on the security of your computer.

[Gul Banana]

It is possible, though it's probably not a good idea.

[Brass]

Besides... you don't even need to use the "root" name to get root access.

You can "sudo" commands, or just "su" to root.

Even if root is not enabled you can still "su" to root with the command:

sudo su -

None of these commands use the "root" username directly.

[Tyre MacAdmin]

the thing is I use the root account probably on a weekly basis or so... sometimes I forget to disable it... I just wanted something a little more bullet-proof just in case somebody finds a way to crack the passwords... a little more obscure so they don't automatically know the username...

[Coxy]

Dude, it's easier to find out the usernames on a computer than the passwords.
Your fears are unfounded. Don't worry about it.

[Tyre MacAdmin]

Originally posted by Coxy:
Dude, it's easier to find out the usernames on a computer than the passwords.
Your fears are unfounded. Don't worry about it.

You're not getting it... that's the entire reason to change the name from root in the first place... If you know it's "root" that's 50% of your job done already... but if its say: 71L3RM(@DAMZ or something completely random, the less chance their is to break it...

[Brass]

Originally posted by Tyler McAdams:
the thing is I use the root account probably on a weekly basis or so... sometimes I forget to disable it... I just wanted something a little more bullet-proof just in case somebody finds a way to crack the passwords... a little more obscure so they don't automatically know the username...

Usernames are in a world readable file at /etc/passwd

(By the way that is where you'd have to change it, as well as NetInfo, perhaps).

So don't think that changing the username will make it secure. Anyone can just look at that file, and find the username with the uid of 0.

[Brass]

By the way, what do you need to log in as root for? If you're truly interested in security, you just won't log in as root at all.

Is it for something you can't do using "sudo"?

I've NEVER logged into the GUI as root, and don't see any need for it. I can alsways su to root briefly if I need to, using the CLI.

[Cipher13]

Unfortunately it isn't that simple. Sometimes GUI root access is necessary - it is when backing this machine up, at least, because naturally I can't read the documents in other accounts, so the Finder chokes on copying folders with unreadable items in them.

Instead, I log in as root and transfer things.

I'll be getting a new iBook soon, so before I do too much with that machine, I'll change the root username through NetInfo (anywhere else I'd have to?) and see how it wreaks havoc with other apps...

[Tyre MacAdmin]

Originally posted by Cipher13:
Unfortunately it isn't that simple. Sometimes GUI root access is necessary - it is when backing this machine up, at least, because naturally I can't read the documents in other accounts, so the Finder chokes on copying folders with unreadable items in them.

Instead, I log in as root and transfer things.

I'll be getting a new iBook soon, so before I do too much with that machine, I'll change the root username through NetInfo (anywhere else I'd have to?) and see how it wreaks havoc with other apps...

Thank you... sometimes it's needed... sometimes it's just easier.. but we're getting off track... I'd tell you why I need it but then I'd have to shoot you ... It's just that big...

[JLL]

Originally posted by Cipher13:
Unfortunately it isn't that simple. Sometimes GUI root access is necessary - it is when backing this machine up, at least, because naturally I can't read the documents in other accounts, so the Finder chokes on copying folders with unreadable items in them.

Instead, I log in as root and transfer things.

You can use Carbon Copy Cloner to backup the Users folder.

Root access is not necessary - just use the right tools.

[philzilla]

Originally posted by Tyler McAdams:
You're not getting it... that's the entire reason to change the name from root in the first place... If you know it's "root" that's 50% of your job done already... but if its say: 71L3RM(@DAMZ or something completely random, the less chance their is to break it...

are you past your 16th birthday yet?

[Tyre MacAdmin]

Originally posted by philzilla:
are you past your 16th birthday yet?

I'm 28 and a mainframe analyst for IBM jackass... changing root userid name is common place in Linux administration... If you don't know how, it would be best not to post anything. thanks.

[Person Man]

Originally posted by Tyler McAdams:
I'm 28 and a mainframe analyst for IBM jackass... changing root userid name is common place in Linux administration... If you don't know how, it would be best not to post anything. thanks.

In other words, he probably knows more about the proper use of the root account (and when to log into the GUI or not) than most of us here. Think before you type. Not everyone needs to be protected from themselves by not logging in as root.

The more you tell people not to do something, the more attractive it is going to be for them to do it.

[Angus_D]

Changing it is completely pointless. Firstly, any user can "nidump passwd ." by default and get usernames (/etc/passwd is not used by default in OS X), and you could probably figure it out using a few lines of code. It's really not worth bothering about.

[Arkham_c]

Originally posted by Tyler McAdams:
I'm 28 and a mainframe analyst for IBM jackass... changing root userid name is common place in Linux administration... If you don't know how, it would be best not to post anything. thanks.

Most of the time when people crack the root account they do not do so by guessing the password. They simply overflow a buffer in the kernel or an app running as root, then insert executable code. The username and password are irrelevant in such an attack.

Internally on UNIX, users are not known by their username, like "root". Root is known as "UID 0", GID "0" to the machine, and you cannot change these values and have a UNIX machine continue to function.

The only workable solution to this problem is simply to disable all login on the root account. That will prevent people from guessing the password, which is all you can do. If you need root capability, run things through sudo. If you can't run something through sudo, log into the console as a user, and launch the finder via sudo.

I've been doing UNIX for well over a decade (SunOS, Solaris, AIX, IRIX, HP/UX, DEC/OSF, Linux, and OSX), and have never seen someone try to rename the root account.

[wadesworld]

I've been doing UNIX for well over a decade (SunOS, Solaris, AIX, IRIX, HP/UX, DEC/OSF, Linux, and OSX), and have never seen someone try to rename the root account.

I agree - it is not at all common to want to rename root.

Wade

[chabig]

changing root userid name is common place in Linux administration

I disagree with this. If it were commonplace, there would be a HOWTO describing it, yet there is not. The others are correct--I have never heard of this being done.

[Millennium]

Originally posted by Arkham_c:
Internally on UNIX, users are not known by their username, like "root". Root is known as "UID 0", GID "0" to the machine, and you cannot change these values and have a UNIX machine continue to function.

Actually, you can assign UID 0/GID 0 to another user, and thus change root's name. In fact, you can even use this trick to have multiple root accounts.

It is not advisable, but it can be done. Changing root's name is nothing more than security-by-obscurity anyway.

[DeathMan]

I think its a common Windows thing to change the Administrator password. This is more about percieved security more than actual security, though. A nice long random password is not worth the effort to crack in most cases.

I've never heard of anyone trying to change the root username before.

[moki]

Originally posted by Tyler McAdams:
the thing is I use the root account probably on a weekly basis or so... sometimes I forget to disable it... I just wanted something a little more bullet-proof just in case somebody finds a way to crack the passwords... a little more obscure so they don't automatically know the username...

what do you use the root account for? You can just do this:

sudo csh

(or whatever shell you want to use) to gain what is effectively a root shell, if you need it. If you're logging in via the GUI as root, well, don't. Really.

[moki]

Originally posted by Cipher13:
Unfortunately it isn't that simple. Sometimes GUI root access is necessary - it is when backing this machine up, at least, because naturally I can't read the documents in other accounts, so the Finder chokes on copying folders with unreadable items in them.\

This is not necessary. The best thing to do is use a backup program that will be able to copy these files for you (after authentification).

Or you can use Terminal to do it if you like:

sudo ditto <files>

For more info on ditto, type:

man ditto

[moki]

Originally posted by Tyler McAdams:
I'm 28 and a mainframe analyst for IBM jackass... changing root userid name is common place in Linux administration... If you don't know how, it would be best not to post anything. thanks.

erm... okay. I've never seen a HOWTO on it -- most of the Linux admins I know simply have their boxes locked down so that root login is only possible when at the console.

They simply use sudo for anything they need to accomplish.

BTW, if you're going to obfuscate the root user name, you'll also need to obfuscate any user that is in wheel, because they are just an sudo away from being able to do anything root can do.

If you want to be really paranoid about it, why not use TCP wrappers to only allow for any kind of remote access from specific trusted IPs?

[Tyre MacAdmin]

Originally posted by moki:
erm... okay. I've never seen a HOWTO on it -- most of the Linux admins I know simply have their boxes locked down so that root login is only possible when at the console.

They simply use sudo for anything they need to accomplish.

BTW, if you're going to obfuscate the root user name, you'll also need to obfuscate any user that is in wheel, because they are just an sudo away from being able to do anything root can do.

If you want to be really paranoid about it, why not use TCP wrappers to only allow for any kind of remote access from specific trusted IPs?

For those of you that have never seen this before... here is a couple threads that describe how to do this on a Linux platform...

http://www.linuxquestions.org/questi...hange+root+uid

http://www.linuxquestions.org/questi...ge+root+passwd

[Tyre MacAdmin]

Originally posted by Arkham_c:
Most of the time when people crack the root account they do not do so by guessing the password. They simply overflow a buffer in the kernel or an app running as root, then insert executable code. The username and password are irrelevant in such an attack.

Internally on UNIX, users are not known by their username, like "root". Root is known as "UID 0", GID "0" to the machine, and you cannot change these values and have a UNIX machine continue to function.

The only workable solution to this problem is simply to disable all login on the root account. That will prevent people from guessing the password, which is all you can do. If you need root capability, run things through sudo. If you can't run something through sudo, log into the console as a user, and launch the finder via sudo.

I've been doing UNIX for well over a decade (SunOS, Solaris, AIX, IRIX, HP/UX, DEC/OSF, Linux, and OSX), and have never seen someone try to rename the root account.

it is indeed possible to change machine values for root... not always an easy process, and is indeed "security-by-obscurity", but most security practices are exactly that anyway.

...as for buffer overflow, this is an entirely different subject, and rather easy if you, say, connect with a telnet session on 20 or 21 an run code for an buffer overflow attack... the best way to keep this is simply allow no incoming connections on those ports. And have the latest updates for you software... you don't have to worry.

tell me, does Solaris allow disablement of the root account?

[Camelot]

Originally posted by Tyler McAdams:
tell me, does Solaris allow disablement of the root account?

No Unix-based OS "allows disablement of the root account". Period.

Sure, in Linux and other variants you can have another account name with root privileges, but as has already been mentioned it is the UID of 0 that defines 'root' privileges, not the name 'root' itself.

Many (most? all?) OS versions (including Solaris and Mac OS X) allow the root account to be locked so that it can not log in or can only log in locally, not remotely.

Any buffer overflow exploit runs the risk of a remote user running code under the UID of the process that's exploited. Under Mac OS X that code only needs to be as simple as 'nidump passwd .' to get the password list and the remote user only then has to look for UID 0 to know what you've called your 'root' account.

The following one-liner will get you the root username on any unix system except Mac OS X:

Code:
awk -F : '{if ($3==0) print $1;}' /etc/passwd

Under Mac OS X you need to use nidump to get the password list, not /etc/passwd, so:

Code:
nidump passwd .|awk -F : '{if ($3==0) print $1;}'

and you're done.

As you can see it doesn't matter what you change the root username to.

If your goal is to enable 'root-level' login to the Finder so you can use it to copy files, then create another username with UID 0 and log in as that, leaving the 'root' account disabled, or use a shell command via sudo.

[moki]

Originally posted by Tyler McAdams:
For those of you that have never seen this before... here is a couple threads that describe how to do this on a Linux platform...

The replies in that thread on linuxquestions.org said it best:

A name is a name (ie apps don't check against "name" but ask for a function to return effective uid etc), but what did you have in mind with it if I may ask? Renaming is in the category of "security through obscurity", in some circumstances counted as a deterrant, this easily turns into a false sense of security

as stated above, this really doesn't provide much in the way of sekurity. Logging in as your re-named root is still very very bad, any exploits aren't going to be looking up the UID of root, and if you are so worreid about people trying to brute force your root password...well you might just want to set a good password and look at your logs

[Millennium]

By the way, you gain no security whatsoever from this. You might, theoretically, get a tiny bit of security-through-obscurity, if you left an account named "root" on the machine without root privileges, thus turning the username "root" into a kind of honeypot.

But this won't fool even the simplest rootkits, so your average script kiddie will still be able to get in exactly as before. A more experienced hacker who doesn't bother with rootkits might be fooled initially, but that would only last for a couple of minutes at best, after which they'll find the real UID-0 account and you're screwed anyway.

Seriously, Tyler; don't bother with this. You gain nothing whatsoever by doing it. Oh, and as for your "logging into the GUI as root is sometimes necessary" bit: it isn't. Well, no, I take it back, there is exactly one case where logging into the GUI as root is necessary: installing WebObjects. For some strange reason, that particular installer requires GUI root access. But there is no reason at all to log into the GUI as root otherwise.

[Angus_D]

Originally posted by Millennium:
there is exactly one case where logging into the GUI as root is necessary: installing WebObjects. For some strange reason, that particular installer requires GUI root access. But there is no reason at all to log into the GUI as root otherwise.

That's a bug that has been long fixed, AFAIK. You might also need to log in as root if you wish to run a 4th Dimension web application on port 80

[BatmanPPC]

[piracy]

I literally can't believe I am reading this thread.

You're sitting here asking how to change the username of the root account to give yourself added security (which it doesn't, at all)...which is really ironic, because if you actually were concerned with security, you would LEAVE THE ROOT ACCOUNT DISABLED and perform your administrative tasks with sudo, or other tools that grant administrative privileges.

No matter what ANYONE in this thread says, you do NOT need to have root enabled, EVER. And logging in as root via the the gui is the ultimate in irresponsibility and laziness. On other platforms and in other environments, is root commonly enabled and used? Yes. Would a responsible sysadmin avail himself of the opportunity to not use it at all, for a variety of reasons, as OS X provides for? Absolutely, beyond any shadow of any doubt (no matter what anyone says here, or what credentials they claim to have).

Additionally, even though people have asked it on other forums, it doesn't prove that changing root's username is useful, just that other people are idiots. Changing root's username gets you nothing when viewed in the context of about 99% of all remote root exploits, because the username itself is immaterial. It's the UID that is important.

The other reason that I can't believe this thread is that no one has managed to come up with the retardedly simple, braindead process to changing root's (or any other user's) username. I don't want to enable this ridiculously irresponsible and nonsensical behavior, so I'm not going to enumerate the steps here. Suffice it to say that if you looked at NetInfo Manager for about 2 seconds (and applied some logic because there are other blindingly obvious steps that need to be followed after any username change), you might be able to figure it out. (It's worth noting that changing root's username would not have, for example, protected against even a single one of the various remote root exploits that have been documented so far on Mac OS X 10.0.x, 10.1.x, and 10.2.x).

[JLL]

Originally posted by piracy:
The other reason that I can't believe this thread is that no one has managed to come up with the retardedly simple, braindead process to changing root's (or any other user's) username.

Many of us knows how to do it, but if you read the posts in this thread again, you'll see that most of the posters probably don't give the answer because they concentrate on telling that it doesn't matter.

[Tyre MacAdmin]

Originally posted by piracy:
I literally can't believe I am reading this thread.

You're sitting here asking how to change the username of the root account to give yourself added security (which it doesn't, at all)...which is really ironic, because if you actually were concerned with security, you would LEAVE THE ROOT ACCOUNT DISABLED and perform your administrative tasks with sudo, or other tools that grant administrative privileges.

No matter what ANYONE in this thread says, you do NOT need to have root enabled, EVER. And logging in as root via the the gui is the ultimate in irresponsibility and laziness. On other platforms and in other environments, is root commonly enabled and used? Yes. Would a responsible sysadmin avail himself of the opportunity to not use it at all, for a variety of reasons, as OS X provides for? Absolutely, beyond any shadow of any doubt (no matter what anyone says here, or what credentials they claim to have).

Additionally, even though people have asked it on other forums, it doesn't prove that changing root's username is useful, just that other people are idiots. Changing root's username gets you nothing when viewed in the context of about 99% of all remote root exploits, because the username itself is immaterial. It's the UID that is important.

The other reason that I can't believe this thread is that no one has managed to come up with the retardedly simple, braindead process to changing root's (or any other user's) username. I don't want to enable this ridiculously irresponsible and nonsensical behavior, so I'm not going to enumerate the steps here. Suffice it to say that if you looked at NetInfo Manager for about 2 seconds (and applied some logic because there are other blindingly obvious steps that need to be followed after any username change), you might be able to figure it out. (It's worth noting that changing root's username would not have, for example, protected against even a single one of the various remote root exploits that have been documented so far on Mac OS X 10.0.x, 10.1.x, and 10.2.x).

You people are jumping to conclusions...

Okay... I never said I did not use sudo... yes I know how to use sudo and it is what I use 99.44% of the time... so please stop posting this as I already know about how to use sudo... this is not what is in question...again: THIS IS NOT WHAT IS IN QUESTION...

as for everyone who says you should never have to log in as root in the gui, I too COMPLETELY agree... once again... this is off track, and really has nothing to do with the post... However... just the other day I had a download that went bad... the file was only half downloaded and got "suck" on my desktop... I could not delete it, so I logged in as root to delete it... this did not work, so I had to reboot into OS 9 to trash the file... this worked since there were no system processes associated with the file in os 9.. so in this case not even root could help... an odd situation to say the least. This is the ONLY time I have had to log into root to do anything since I do in fact use sudo... Okay... so now that we have down that I use sudo and don't log into root, we can actually get to my post question: CAN ROOT BE RENAMED? That's the only thing I need to know besides maybe how to do it.. a simple yes/no question that has nothing to do with me using sudo or logging in to my workstation as root. your opinions on how effective a security policy it is to such a thing is your opinion, and are welcome opinions. And yes, I leave this account disabled... again not part of the question...

[philzilla]

Originally posted by Tyler McAdams:
Okay... so now that we have down that I use sudo and don't log into root, we can actually get to my post question: CAN ROOT BE RENAMED? That's the only thing I need to know besides maybe how to do it.. a simple yes/no question that has nothing to do with me using sudo or logging in to my workstation as root.

Originally posted by piracy:
Suffice it to say that if you looked at NetInfo Manager for about 2 seconds (and applied some logic because there are other blindingly obvious steps that need to be followed after any username change), you might be able to figure it out. (It's worth noting that changing root's username would not have, for example, protected against even a single one of the various remote root exploits that have been documented so far on Mac OS X 10.0.x, 10.1.x, and 10.2.x).

VOTE PIRACY

[Tyre MacAdmin]

Originally posted by philzilla:
VOTE PIRACY

Okay Piracy wins... somebody give them a cigar... but my question is still not answered.

[piracy]

Originally posted by Tyler McAdams:
Okay Piracy wins... somebody give them a cigar... but my question is still not answered.

Okay.

Imagine that someone told you that if you placed a special purple-colored brick on your front lawn that it would protect you from robbers, and then you come here asking where you can obtain one of these special purple-colored bricks.

What I am trying to tell you is that the purple-colored brick DOES NOT in fact protect your house from robbers, regardless of what someone else tells you, or what you think. Therefore, you do not need such a brick.

Yet you still want this purple-colored brick... interesting.

-----

Side note: whether the root account is enabled or disabled, changing root's username provides you no additional protection. Remote exploits are not dependent on the username at all, and any user with local access can trivially reveal root's "new" username.

That said, the process for changing any user's username ("short name") is as follows:

1. As any admin user OTHER than the user whose username is being changed, launch NetInfo Manager.

2. Change the 'name' (and 'home', if desired) properties of the user as appropriate.

3. There is no step 3.

(If the home directory property is changed, the home directory itself will also have to be renamed. Be advised that parts of the OS may have dependencies on users that you are not aware of. Be further advised that there is some local directory ['directory' here means users/groups, not the filesystem] data that may also be dependent on the username. File ownership is not an issue as the UID has not been changed.)

Best wishes with your brick.

[Tyre MacAdmin]

Originally posted by piracy:
Okay.

Imagine that someone told you that if you placed a special purple-colored brick on your front lawn that it would protect you from robbers, and then you come here asking where you can obtain one of these special purple-colored bricks.

What I am trying to tell you is that the purple-colored brick DOES NOT in fact protect your house from robbers, regardless of what someone else tells you, or what you think. Therefore, you do not need such a brick.

Yet you still want this purple-colored brick... interesting.

-----

Side note: whether the root account is enabled or disabled, changing root's username provides you no additional protection. Remote exploits are not dependent on the username at all, and any user with local access can trivially reveal root's "new" username.

That said, the process for changing any user's username ("short name") is as follows:

1. As any admin user OTHER than the user whose username is being changed, launch NetInfo Manager.

2. Change the 'name' (and 'home', if desired) properties of the user as appropriate.

3. There is no step 3.

(If the home directory property is changed, the home directory itself will also have to be renamed. Be advised that parts of the OS may have dependencies on users that you are not aware of. Be further advised that there is some local directory ['directory' here means users/groups, not the filesystem] data that may also be dependent on the username. File ownership is not an issue as the UID has not been changed.)

Best wishes with your brick.

Thanks.

[Hozie]

Originally posted by piracy:
Okay.

Imagine that someone told you that if you placed a special purple-colored brick on your front lawn that it would protect you from robbers,

...

Best wishes with your brick.

[philzilla]

someone who needed telling how to do something so simple in NetInfo, shouldn't even be opening NetInfo, in my opinion

wanna buy some bricks?

[Tyre MacAdmin]

Originally posted by philzilla:
someone who needed telling how to do something so simple in NetInfo, shouldn't even be opening NetInfo, in my opinion

wanna buy some bricks?

Look.. not everybody makes there living on Mac OS X. You can either be helpful and answer my question... or you can be a smart ass and tap dance around it an say stuff like are you 16? It's funny how much of an ******* you can be... HIDING BEHIND YOUR COMPUTER. You want to talk **** you can do it to my face if your man enough.

Moderators pleae close this subject as my question has been answered. thx

[Moose]

Originally posted by Camelot:
No Unix-based OS "allows disablement of the root account". Period.

Ah, not so:

FreeBSD-Current /usr/src/sys/kern/kern_prot.c:
/*
* `suser_enabled' (which can be set by the security.suser_enabled
* sysctl) determines whether the system 'super-user' policy is in effect.
* If it is nonzero, an effective uid of 0 connotes special privilege,
* overriding many mandatory and discretionary protections. If it is zero,
* uid 0 is offered no special privilege in the kernel security policy.
* Setting it to zero may seriously impact the functionality of many
* existing userland programs, and should not be done without careful
* consideration of the consequences.
*/

In plain English, this disables root. Completely. You will either need to do a hard boot (reset switch, yank the power, etc.) or, if you compiled your kernel with ddb, drop to the debugger, and put a 1 back in that variable.

[sandsl]

Originally posted by Tyler McAdams:
Moderators pleae close this subject as my question has been answered. thx

Um...great your question has been answered and I'm pleased for you. Trouble is this board isn't a Q&A site, its a dicussion forum, threads shouldn't just be locked when you've got your answer.

[Tyre MacAdmin]

Originally posted by Moose:
Ah, not so:

FreeBSD-Current /usr/src/sys/kern/kern_prot.c:
/*
* `suser_enabled' (which can be set by the security.suser_enabled
* sysctl) determines whether the system 'super-user' policy is in effect.
* If it is nonzero, an effective uid of 0 connotes special privilege,
* overriding many mandatory and discretionary protections. If it is zero,
* uid 0 is offered no special privilege in the kernel security policy.
* Setting it to zero may seriously impact the functionality of many
* existing userland programs, and should not be done without careful
* consideration of the consequences.
*/

In plain English, this disables root. Completely. You will either need to do a hard boot (reset switch, yank the power, etc.) or, if you compiled your kernel with ddb, drop to the debugger, and put a 1 back in that variable.

Wow... such a straight forward consise answer... thank you!!

[Brass]

Originally posted by piracy:
I literally can't believe I am reading this thread.

You're sitting here asking how to change the username of the root account to give yourself added security (which it doesn't, at all)...which is really ironic, because if you actually were concerned with security, you would LEAVE THE ROOT ACCOUNT DISABLED and perform your administrative tasks with sudo, or other tools that grant administrative privileges.

I mostly agree with your comments. However, I think that the sudo command itself is terribly insecure. I agree that it is far better to use sudo to do work as root than to login to the GUI as root.

However, "disabling" root is not particularly useful, as it doesn't really disable it at all, it just prevents GUI login as root. You can still sudo anything as root, even sudo su - (ie, su root) and become the root user. So the root account is certainly not what I'd call disabled.

I usually do exactly what you suggested, and sudo anyting that needs to be done as root. However, I don't believe it is more secure than enabling root.

On many Unixes (eg, Solaris), the sudo command does not even exist, by default, because of its inherant insecurity. It's far more secure to have to sudo command and have the root account enabled with an obscure password, than to have a sudo command and a "disabled" root account. With the sudo command, you don't need to know root's passord... any user in wheel group's password will do to get you complete root access! (you can even enable root then if that would help any further).

[Brass]

I could be wrong, but I believe that if you were to change root's username you do need to do it in /etc/passwd to be complete.

I know that it must be done in netinfo, and in most cases that is all you need, but if you want to be complete, you'd have to do it in /etc/passwd as well, as that's what is used in single-user mode.

Although changing the name in single-user mode is pretty useless, I don't believe it's much more useless than changing it for the full run level.

[theory]

sudo is not insecure. All it does is change the setuid bit on in the executable
you are trying to run. You can already
do this by using chown/chmod

[Brass]

Originally posted by theory:
sudo is not insecure. All it does is change the setuid bit on in the executable
you are trying to run. You can already
do this by using chown/chmod

If that is really what sudo did it would be even more insecure!!! However, that's not what it does, thankfully.

The sudo executable itself has the setuid bit set, and that's how it works. Other than that, all it does is switch user and run whatever process you tell it to.

So effectively, it is switching the uid (and gid) of the process, NOT changing the setuid bit on the executable, which would be a disaster - it would have to switch the setuid bit back again afterwards, and then if it crashed while running, that executable would be left for anyone to run as root (or whoever) anytime without requiring sudo.

sudo is insecure on a system with more than one admin (wheel) user, because there are more passwords which will allow it to be used (you only need to know one password from any of the admin users). When people do not have a sudo command on their machine, and users need to su to root to access root privileges, then people are more inclined to set a non-trivial root password. This is secure. However, if there is a sudo command, and there are several admin users, the chances are much less that they will all have good secure non-trivial passwords.

I'm not saying that sudo is always a security problem, but just that for cracking passwords (and for no other reasons) sudo is more inclined to being insecure than having root enabled with a good password.

Edit: To backup my argument about what sudo actually does, here's a quote from the man page ("man sudo"):

sudo allows a permitted user to execute a command as the superuser or another user, as specified in the sudoers file. The real and effective uid and gid are set to match those of the target user...

[Brass]

Originally posted by theory:
sudo is not insecure. All it does is change the setuid bit on in the executable
you are trying to run. You can already
do this by using chown/chmod

PS. You cannot use chown/chmod on an executable you do not own (or at least have write access to). In most cases this means you have to be root to use chown/chmod on any standard OS executable (or anything you would usually use with "sudo").

So that statements only holds up if you use chown/chmod in conjunction with sudo, which nulifies the argument