No write permissions for admin group
 

Just bought my new mac, so I'm not yet familiar with osx.
when I tried to install some application and copy a file to /usr/bin I got a window saying that I don't have permissions to do that although my account belong to admin group.
I have found that most of the subdirs under / are owned by 'wheel' and not admin, and admin group don't have right permissions to those folders.
what do can I do to fix that, and how can I remove the annoying admin password request each time I do almost anything?

If you're copying files to /usr/bin, that's the first no-no. /usr/bin is a directory that can be overwritten by system updates at any time. Only the entity responsible for the operating system (in this case, Apple) should write to /usr/bin.

If you'd like to add command-line apps to your new Mac, that's no problem. Just

1. add /usr/local/bin to the front of your PATH in your shell's configuration file, for example in ~/.bashrc or ~/.bash_profile
2. create /usr/local/bin and copy your command-line apps that you would like to add there.

That all said, if you need to copy files to a directory where you don't have permission, and you are in the admin group, then you would prepend sudo to the copy command, and when you are asked for your password, enter it (blind--nothing is echoed back to the screen). Note that when using sudo, it is asking for YOUR account password, not a special password such as the root user.

Just don't put anything in /usr/bin.

Trevor

Not to say Trevor is wrong, his set up is pretty efficient and way more safe, but I have successfully put both scripts and binary files in /usr/sbin that are third party and they work just fine. Just make sure you know what you are doing because you do run the risk of crashing the whole system.

Trevor's method is best practice because it can only hose your user level preferences and not mess with the system.

Yeah, I suppose I should clarify that adding command-line apps to /usr/bin (or /usr/sbin, or /bin, or any of the operating system's directories) will work, at least temporarily. It's just a bad idea. And if you REALLY want to do it, then you can using the sudo command explained in my post above.

But it's just easier in the long run to put your own stuff into it's own directory, and from long Unix tradition that directory is /usr/local/bin.

Trevor

Like for example, the jamf client which is on every single machine at work installs the binary into /usr/sbin. I don't put it there their pkg installer does. Never had a problem with it at all so far. Some of the problems are though if you start putting things in there with wrong permissions and ownership it can be looked at very bad practice.

I just like to put things in the standard $PATH so I can run them as I see fit, then again I am not an average user either.

++

Many things may "work"... but right is right.

Protocol has many meanings, and they all apply here.
jamf sounds somewhat presumptuous.
clamXav is proper and polite.

PATH=$(echo {,/usr{,/local}}/{,s}bin ~/bin |/usr/bin/sed 's@ @:@g') ;)

That's why you need to look very carefully at installers and override their default install dir if need be.

As Trevor has said, it is better to extend your PATH to include /usr/local and any other folders where you install 3rd-party stuff.
And to leave the standard system dirs like /usr/bin to Apple.
That way you know what comes with the standard install and what you installed after.

Well it is a system daemon, that is basically a lot like launchd, and doesn't need a user logged in for it to run. It always runs. I am not software developer but I am sure there is a reason behind what they did. I am not defending them either, and then you have other developers that put retarded applications in /Library for no apparent reason. I typically just get rid of those all together.

Then there is Adobe, and well, this is getting off topic so I will stop, but my point is I think there is valid reason to put certain things under the hood in OS X and not just refer to them in a user specific bash profile.

Just being a daemon doesn't mean it's a lot like launchd.

This is a bad assumption.

It is like launchd because it is also designed to manage systems that do not have access to a OS X Server and may be part of a Windows domain. It can take over the whole system, black/white list processes, and much much more.

You can enable and disable services, it is a full on framework.

Unless, I have it all mixed up.

It may sound weird, but the there isn't 'local' directory under /usr. and since i don't have write permissions to /usr i can't create one. what is going on?

You need to use 'sudo' to get 'root' privileges to create the /usr/local directory.

sudo mkdir /usr/local

What I'm driving at is that launchd manages everything but the kernel in Mac OS X. It literally is responsible for bootstrapping the system after the kernel invokes it as pid 1.

I know Mikey, and the jamf client uses all built in Unix commands from apple to do the same thing, but it simplifies it and gives it a web based front end for configuring frameworks. They make it so you don't need to know Unix to accomplish tasks that normally Unix gurus would know. The binary checks in every so many minutes, updates the frame work as need be which you can do from the web front end, will kill processes if they are black listed, can create and delete user accounts, bind your client to AD, and all kinds of stuff you may want to manage your Macs with if you didn't have OS X server to do it. Like a Mac deployment in a Windows centric network.

The OS X boot process is, Power > POST > EFI/Firmware > launchd > loginwindow

I know that launchd rules them all. I am not trying to argue with you guys, I know you, Hayne, Hal, & Trevor are all really smart people. I just think that there are valid reasons to put things in the under-the-hood Unix of OS X.

I'm not sure what that means. Are you saying that -- besides /sbin -- they have extensions
(or whatnot) in /System/Library somewhere?

No matter, our point here is that: there's no "technical" advantage of trampling into /sbin.
Had they created /usr/local/sbin and put their binaries there, it would work just the same.
The only tricky issue being the $PATH definition... which may be why they did it that way.
(i.e., part laziness and part "it will always work, because /sbin is in everyone's $PATH".)

--

Both /sbin and /System are in Apple's domain however... and any given update could wipe
out extraneous items there, at any time (without warning). The /usr/local area is normally
left undisturbed at all times (else, that would be Apple's bad).

I am not saying I disagree with any of those statements, I am just saying there are valid reasons. The JAMF binary has a long list of commands that uses the under the hood Unix of OS X.

It allows me to change my 15 to 20 line create user script to a 2 line jamf command and accomplishes the same task. /usr/sbin will never be touched or changed and can never be touched by a local user unless they can sudo.

Yes but, Apple might "touch" it the next time you run an OS update.
I'm not saying they *will* mind you... but we sure can't be sure. ;)

Thanks, but the point is not really how smart we are. The fact is, Unix has been around since 1969/1970, first from Bell Labs, then starting around 1977 the BSD version was developed and widely propogated.

In that time, many people much smarter than us worked with Unix, and over time discovered (often painfully) that there are some things that you can do, and some things that you just cannot do with it.

One thing that was shown, over and over again, is that the end user must leave the directories used by the operating system alone. They are completely free to add their own tools as much as they want, but they need to put those tools into their own directories, not trampling on the operating system's directories.

If it is true that each new generation thinks themselves smarter than the previous generations, and can get away with shortcuts and duct tape fixes, then it is also true that each new generation will have to learn for themselves, the hard way, of the wisdom of "the right way" to do it.

Trevor

In this case I am not the end user though, I am the systems administrator. This is for an enterprise environment and not an end user machine. I have this set up and working on over 6,500 macs. There is a deployment up in Minnesota with over 12,000 Macs doing pretty much the same thing that I am.

I have been tossing certain things in the standard $PATH for years now, and while everyone has always told me the same thing you guys have, I have not had any issues. Of course I toss things in there that I test like a billion times before I ever put it out in production. I also disable software update and don't allow end users to update anything that isn't approved and tested.

I have tossed several custom shell scripts in the standard $PATH and then created launchd items that execute that path, like /usr/sbin/myscript.sh for example.

I am just really playing devil's advocate here is all.:D

That's exactly the problem. As an administrator, why don't I get the 'root' privileges automatically?

I'm a kernel developer for several unix based platforms, so I thought that I'll be just fine with OS X, but I find this whole thing really annoying.

BTW what is this 'wheel' group?

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...]