Because -- in OSX Client -- admins are not "automatically" root-privileged.
If you want omnipotence, grab a root shell: sudo -s


gid =0
It's the companion to uid = 0 (root),
and only root shall be a member.
Thus sayeth the [BSD] Unix Lord. ;)

admin is not root
An admin account is one which can attain root privileges temporarily (for one command) by using 'sudo'.

The 'root' account is disabled by default in OS X since it is a security risk to be logged in as root - especially in a GUI.
And all uses of 'sudo' are logged - which is an advantage.

Note also that the 'sudo' command only prompts for a password if it has been more than (by default) 5 minutes since your last use of 'sudo'.

I'm not sure I understand the question. As an administrator (or more precisely as a member of the admin group), you get access to root privileges automatically, because in a default install OS X has /etc/sudoers set to include the line
meaning that anyone in the group admin has sudo access to all root privileges. If you would like a more secure setup, you can limit this privilege.

So, as an administrator, you DO get root privileges, simply by using sudo. Sudo access is logged (another good security measure) in /var/log/system.log and /var/log/secure.log. Sudo usage also has some other security features built in.

Because you have to type sudo, you find that annoying? Which unix-based platforms are you referring to? I can't think of any brand of unix that gives just anyone root privileges--you have to log in to the root user to get root privileges, or use su or sudo, the same as in OS X.

It is root's group. A much more verbose explanation is here: http://administratosphere.wordpress....e-wheel-group/

Trevor

No one said it doesn't "work" (quite the opposite in fact), just that it's not kosher.
Granted, there's no guarantee that Apple will erase non-Apple items in those areas,
(quite the opposite in fact). It's just that --if/when it ever does happen-- they will be
fully within their rights to do so.

That's why i figured the sudo -s shell would be a good choice for yonio.
He said he's already "annoyed" -- why let 5 minute time-stamps add to
that frustration? A sudo -s shell will last until the user types control-D.

;)

That is incomplete. After EFI/OF inits the device tree, the bootloader loads the kernel. If there is a kernel cache available, that gets used to circumvent having to link in all the necessary device drivers. Kernel is then responsible for bringing up IOKit and then launchd is started to complete the startup procedure and manage system processes.

It's not just something that runs scripts. It's the root parent process of all processes in Mac OS X.

Yeah I agree, but I also think if Apple starts breaking third party compatibility it will royally piss off their user base. I remember when 10.5 came out and the amounts of things it broke, and I met some unhappy Apple users. It has worked for me from the beginning, and I have done it in Linux too. A lot of developers do that, and they also create directories too like /opt and so forth. I haven't ever seen a system update get rid of my launchd scripts that I toss in /usr/sbin. Maybe it will happen one day, and I will be broken of my bad habits, but I don't think Apple is really going to tweak the Unix end that much more than they already have.

As for the sudo thing. When I do extensive terminal work I use first authenticate using sudo -s which opens up a root session in terminal and I am not sure if there is any time out.

But if developers are doing incorrect things, whose fault is it?

I remember when Leopard came out and Unsanity broke it severely because they were doing things they weren't supposed to be doing. And then Logitech was silently installing Unsanity's broken software and breaking more Leopard installs.

I'm not getting into the /sbin argument, but you're making a lot of fundamentally flawed assumptions in this thread.

You seem to be grouping both of these practices in one category, but that's not appropriate.

The "lot" of developers who write to the system directories are wrong. On the other hand, the developers who create directories like /opt are just fine. /usr/local is traditional, but not at all required. If developers want to create new directories like /sw (used by fink) and /opt, that's just fine.

Trevor

The 'sudo -s' shell is a good tool to have at your disposal. I use it myself when I have an extended amount of stuff to do that requires 'root' or (especially) if I need to 'cd' into root-only directories.

But I don't recommend it as a general use anytime you need to run a few commands with 'root' privileges. A certain amount of "annoyance" is good - it reminds you that you are doing something that might break the system. And anything that slows you down when doing such things is good.

Quoting this for so much truth it practically hurts.

Yeah I agree with you Mikey, I am just saying it is possible. While I have read through a lot of the Apple white pages I have also seen countless developers put stuff where it doesn't belong. I think Apple does look out for this type of stuff to some extent, especially legit third party developers.

While, I know I have bad habits, I don't see Apple wiping out my scripts I put in /usr/sbin and there are certain reasons I don't like putting things in user folders, especially with things like 'repair permissions.'

Also, Apple doesn't always make it easy, and some developers are clueless and I don't know everything. I just get by with what I can.

Agreed (and, i myself don't leave such shells laying-in-waiting.
i do what needs doing and then control-D out of there).

I was making that special recommendation to yonio...
"a kernel developer for several unix based platforms,"
who found "this whole thing really annoying". :)

--

sudo alone only gets us so far.
We cannot do this for example:
sudo cd /var/db/dslocal/nodes/Default
[so it's either type long pathnames or...]