authentication for running scripts

[yellow]

Greetings,

I am attempting to set up a simple terminal script that will run on Joanne Q. Public's home OS X box to configure ipfw with our departmental ruleset. The problem is authentication. I don't want to have to confuse our zero-UNIX experienced users with notions of root, sudo, and administrative authentication. I just want them to unpack what I send and type a simple string to run the script in a terminal window. Is this easily accomplished by someone who has minimal scripting experience? I've come up empty on man pages.

Forgive me if this is not the right forum for this question.
Thanks for any help!

Jacques

[mervTormel]

yellow,

you may get some good help from this thread...

http://forums.osxhints.com/showthread.php?s=&threadid=192


posts from forum user Navajo mention...

...the Right Way of doing things for authenticating and running commands with privileges in Mac OS X seems to be to use the SecurityFrameworks,as discussed at [ stepwise url, see thread ].


i really think it would be a good idea for even general users to have to authenticate your scripts.

N.B. from the sudo man pages...

sudo - execute a command as another user

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 as specified in the passwd file
(the group vector is also initialized when the target user
is not root). By default, sudo requires that users
authenticate themselves with a password (NOTE: this is the
user's password, not the root password).

[yellow]

Merv,

Thanks for responding. Actually before I posted, I read all those posts and as far as I can tell, that built in authentication is for an app that runs under Aqua (cocoa?), and/or a C++ program, not with a terminal script.

I am quite familiar with sudo, I just don't get paid to support these people's home machines and I don't have the time or the will to sit them down and explain to them how to set up root and then add themselves into /etc/sudoers.

I was hoping for an easy way out of this, but from everything I can find there is no simple way to do it (which I guess would be expected, for security reasons) and I'll just have to come up with plan B. Thanks for your time and post!

Jacques

[mervTormel]

if this is at user's home OSX box, they are already an admin, and are already in the sudoer's file.


% cat /etc/sudoers
# sudoers file.
#
...
# User privilege specification
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL


so, the only thing they have to type after running your package is their password when sudo is invoked. right?

easy peasy

[mervTormel]

addendum:

yellow, i re-read this thread from the beginning to try and get this right.

one thing your users will have to do to enable sudo is launch

/Applications/Utilities/NetInfo Manager

and select menu item Domain->Security->Enable Root User

and authenticate this. else, i believe, there will be no root access thru su or sudo, or even login, perhaps.

but, after that, then authenticating terminal sudo invocations with the _user's_ password is trivial.

let us know if that helps solve your issues.

[pmccann]

Hi MervTormel,

They definitely don't (indeed *shouldn't*, I believe) activate the root account.

The sudo interface works just fine without this set up (which is why I shed another tear each time someone recommends a solution that involves first going into Netinfo manager and setting up root when it's not necessary. Nota bene: I'm not referring to your post!!)

If they want a root shell then "sudo -s" or "sudo tcsh" or whatever work beautifully. But for Jacques original request I'd recommend something like a shell script "shellscript" that he could write, and have the user execute it via

sudo sh shellscript

that way there's no need to talk about making the thing executable, or any other nonsense. They just put the file "shellscript" wherever they want it, type the above line and enter a password. It's as safe as I can manage, assuming a novice user.

Cheers,
Paul

[yellow]

Thank you for your posts,

Well, that answers that. I guess one part of the problem was, I didn't remember if sudo would work right out of the box. It's been a few months since I set up my 2 OS X boxes and as a KED (Knows Enough to be Dangerous) UNIX user, I had enabled root and addded myself into /etc/sudoers. After learning ipfw, I decided that I better develop a simple installer to distribute to anyone who might need it in our department.
Well, thanks to both of you for all your help!!

Jacques

[mervTormel]

paul,

thanks for the correction. i just NetinfoMugger disabled root user, and sudo still works. wha?!

hmmm, coulda sworn reading about how to get sudo working way back in 2001, by enabling root user, but perhaps that was just for su ? hang on, lemme check, gimme yer lighter...

yep, su root now tersely apologizes.

so, can anyone tell us what impact leaving root disabled has on an installation, other than tighter security for the superuser account?

in other words, does enable root user only make su work, or what other implications are there?

TIA

[yellow]

Cool, a question that I have input on!

DISCLAIMER: If you are a novice user of Mac OS X and you have no UNIX experience, there's really no need to enable root as 99.9% of the things that you need to do can be done in the Aqua interface with your administrative password. Playing with root can seriously jeopardize the integrity and stability of your computer's operating system.


Now, there are certain instances when you will need to be root on the console*. You can do this by 1) enabling root, 2) in the System preference Panels, select Login, 3) select the Login Window panel, 4) select the "Show 'Other User' in list for network users" button, quit the System Preference Panels, 5) select Log Out from the Apple menu.

You should not be able to login to your machine as root, rather than as the administrative user. This gives you FULL control/permissions on the machine.

Again, this is not necessary and not advised, unless there are specific actions that call for you to do this.

Jacques

* One instance is when a poorly written 3rd party SystemPref panel doesn't function, you cannot remove these items. As the administrator, you don't have the permissions to remove potentially important things like that. Logging into the console as root, however allows you to do whatever you like.

[mervTormel]

i find it ill-advised to login to yer OSX as root. that is, on the login screen, enter root (is that even a username? or do you log in as system?)

i have never done it and see no need. to many uncontrollable things happen if you log in as root. and i don't want to maintain the root account. i want it to remain very vanilla, otherwise, i can't predict behaviors.

all rooty type activity can be done in terminal with sudo

---
* One instance is when a poorly written 3rd party SystemPref panel doesn't function, you cannot remove these items. As the administrator, you don't have the permissions to remove potentially important things like that. Logging into the console as root, however allows you to do whatever you like.
---

that depends on how it was installed. if i (as my admin account) am given a foo.prefPane and i copy that to my ~/library/preferencePanels folder, i am owner and can have my way with them. [ be sure to quit the system preferences app before trying to remove them as the panes prolly stuck their fingers in their prefs files and they are open, which precludes ability to delete them outright, thank Bog ]


% ll Library/PreferencePanes/
total 8.0k
drwxr-xr-x 3 me staff 264 Oct 16 16:29 ASM.prefPane/
drwxrwxrwx 3 me staff 264 Jan 27 06:11 FruitMenu.prefPane/
drwxr-xr-x 5 me staff 264 Jan 10 01:03 MouseZoom.prefPane/
drwxr-xr-x 3 me staff 264 Dec 13 09:24 TinkerTool.prefPane/


now, if i'm required to install a prefPane, and it asks for authentication, then i suspect that it could be owned by root, be troublesome to delete from the finder, but not CLI.

[yellow]

I agree, that's why I included the disclaimer :-)

Anyway, you're exactally right. The installer uses the authentication discussed in another thread* and places the files as root with the admin group. I was unable to uninstall, could not rm them as myself (admin) or with sudo (strangely).

drwxr-xr-x 7 root admin 194 Dec 12 14:06 ./
drwxr-xr-x 4 root admin 92 Dec 12 14:06 ../
-rw-r--r-- 1 root admin 794 Dec 12 14:06 Info.plist
drwxr-xr-x 3 root admin 264 Dec 4 20:52 MacOS/
-rw-r--r-- 1 root admin 8 Dec 4 20:52 PkgInfo
drwxr-xr-x 7 root admin 194 Dec 4 20:52 Resources/


* http://www.stepwise.com/Articles/Technical/2001-03-26.01.html

[mervTormel]

yellow,

thanks. re: that listing; what was that installation of?

what is/was the permissions on the parent dir?

curious that sudo couldn't vaproize that stuff, clearly a perms issue, tho.

[yellow]

I inserted it into my previous post.