Edit 'hosts' by non-administrators
 

Hi,

I've been digging around for this one. To my knowledge there is no way allow non-admin/root users to edit the /private/etc/hosts file.

We have a group of programmers that on occasion needs to modify this file to point to test servers temporarily. They have asked that we grant them the ability to change the file w/o an administrator.

We have tried changing the permissions (chmod) on the /etc/hosts file, but OS X ignores the changes we've made and still will not allow the changes w/o first performing a sudo and authenticating.

It appears this is by design. We've tried to explain this to the programmers, but they have put a little more pressure on IT Support to overcome this.

Has anyone been successful?

it works just fine for me:

I suspect that the resetting of permissions referred to by RickNTpa happens when the Mac in question gets restarted.

I just tested on 10.5.6 and 'chmod o+w' persisted across a reboot.
But if that is indeed the problem, the simplest solution is probably to have an administrator write a quick script that sets the desired permissions, chown it to root:wheel and setuid it.

...then watch a cracker who has only gained unprivileged access exploit that big security hole to get root.

This may be the simplest solution, but it is a very bad idea. Writing safe scripts that are setuid is very difficult.

Trevor

Why do the engineers not have administrator access to their own computers? If the engineers where I work were constrained like this, nothing would get done.

Central server perhaps?

On my machine, /etc/hosts is rw-rw-rw, has been for months, and I have scripts that create new sites and install databases without needing admin access or passwords. Takes about 15 seconds to create a new site with a CMS.

Writing a script that does dynamic operations and is setuid and is secure is hard, I would agree on that. Writing a script that does exactly one thing statically and always executes the exact same command is different, though. As long as no one can alter the script (it's owned by root:root and is rx only) there's nothing else the script can do that wouldn't require the cracker to already have root access.

Though thinking about it it would be just as feasible to give at least one developer permissions to use sudo to change permissions on just /etc/hosts.

suid scripts have been disabled for a while (since Tiger?), making both points rather irrelevant.

It's silly for a developer not to have full access to the client machine he or she is using. If any of the engineers where I work didn't have the ability to use their machines as they needed, it would be a nightmare.

They're software developers. If they can't use a computer well enough to be granted rights to use it effectively, they should get another job in the first place.

Sometimes the reason for imposing restrictions like this is that the network administrators don't know how to secure the network if there are any unrestricted machines on the network. I've even seen cases where admin access was restricted since the same password was used for the admin account on all machines!

I tried that on my web hosting provider. They still wouldn't give up the root password :(

Are these users logging into OD? I suspect maybe MCX is doing something here. Also you could add the engineering group the little flag that says let them administer the computer, but I can see some security holes.

My question is, if they are developers, do they not have a test machine that is off the network, like a sandbox set up or some sort?

This is a case where virtual machines would come in real handy in OS X.

I'm not talking about getting root on your web host; the OP is telling us that the developers do not have access to edit a file on their own computers:

They're not normal users, they're not even power users. They're developers. Crippling their tools is the wrong way to solve whatever problem this is intended to solve. If they can't handle this kind of responsibility, they suck and shouldn't be working there. If it's the fault of the network admins, they suck too.

Mikey, well by that logic I have worked with a lot of people who have sucked, and I myself have sucked at times too.

I would say this is a management issue not a department or IT issue. If I were the network admin there I would say whatever management says is the way I will do it. Now if I was the IT director, then I would probably give developers admin access and then hold them responsible for their actions.

Good point. I looked it up, and they've been disabled since OS X 10.3.9.

Trevor

Simple (Non Unix) way to edit the hosts file.
 

All over the web, the answers to editing the hosts file seem to be a lot harder than they have to be. Or am I missing something?

Under the GO menu in Finder, select "GOTO Folder"
Type /etc
Find the "hosts" file by name
Double click on it and it will open in text edit.
Edit and Save?

The issue is one of permissions - you won't have permission to save the file since it is writable only by 'root' (as is the enclosing folder).

Perhaps a simple solution?

Edit the sudoers file with visudo. Add:

Now all users that are a member of the group 'developers' are allowed to edit /etc/private/hosts on host1, host2 and host3 using sudo -e /etc/private/hosts.

Don't be tempted to put "vi /etc/private/hosts" in there. That would give them unrestricted root access ( in vi: ESC :!/bin/sh ).

Well, there are two problems with that. 10.5 appears not to have a sudoedit command, it also appears sudo does not honour the -e flag. (Oh, and you have the path wrong - it's /private/etc/hosts.)

However, you will find that replacing 'sudoedit' with 'rvim' works just fine and doesn't allow suspending or shelling out.

// Tony

honestpuck, 10.5.x /usr/bin/sudo honors the -e flag, but in testing it seems to always try to force the file to be in /var/tmp (no matter what path you gave the filename) and appends a 6 character, seemingly random file extension on the end of the filename. It's not particularly clear to me what it is trying to do.

Trevor

Yeah, that's the behaviour I saw. On a Linux VM I have it works great but on 10.5 it's broke. I guess I could have been a little more explicit, it does try and do something but does it broken.

On my testing I also saw that sudo seems to much prefer the "%" flag than the "+" flag and also wants the path to the command to be explicit as well so the line should have '/usr/bin/rvim'.

Suffice to say that some experimentation with the exact syntax is probably required - my testing was complicated by the fact that both the accounts I use on both my Macs are already listed in sudoers.

// Tony