[wataru]

I need to run a command as root from within a shell script, but I can't have the script itself run as root. If possible, I'd like to use the standard OS X authentication dialog, but I have no idea how. It looks like /System/Library/CoreServices/SecurityAgent doesn't work that way, and neither does SecurityServer. Does anyone know how to do this?

[utidjian]

What is the command you need to run with root privs?

[wataru]

Originally posted by utidjian:
What is the command you need to run with root privs?

vsdbutil. It's kind of complicated why I can't just run the script itself as root. If you really want to know I'll post about it later.

[utidjian]

Originally posted by wataru:
vsdbutil. It's kind of complicated why I can't just run the script itself as root. If you really want to know I'll post about it later.

Yeah... I am kinda interested. Looks like vsdbutil is sort of problematic in itself. Essentially if you turn off privs on the disk it becomes somewhat meaningless who or what root is... it makes everyone root on the particular volume.

The reason I ask is that there is usually a way to get the thing(s) you want done done without compromising the security of the system.

[wataru]

All vsdbutil does is toggle the checkbox "Ignore ownership on this volume" in the Finder's Get Info window for volumes. You can't use it to eliminate permissions on root, so it's really not much of a security risk.

I want to call vsdbutil from my app, iPodBackup, so that I can enable permissions on the target volume, which is either an iPod, or a disk image on the iPod. By default "Ignore ownership" is enabled, and for some reason that results in rsync, the core of the app, wasting a lot of time re-copying directories that haven't changed. It seems like the problem is that it can't figure out what's newer than what, like perhaps the date is tied in with permissions in some way. That's just my guess.

The bottom line is that disabling "Ignore ownership" makes rsync smarter and faster, so I'd like to disable that automatically from within the app. The only way to do that seems to be vsdbutil, but unfortunately that requires root access to actually modify the setting in question. I don't understand that, since you don't have to be root in order to toggle the option in the Finder.

So why can't I have the script run as root? I turn the script into a double-clickable app via Platypus, which allows you to make the app require an admin password to run. But, for some reason, one of the other commands I call from within the script doesn't work properly when run as root (hdiutil fails to properly create a disk image for whatever reason), plus I've had other permissions snafu's in the past due to running as root, so I'm trying to avoid it. Plus, I tried making a test app that uses vsdbutil and requires authentication, but it still didn't work.

So that's the problem. I need to run vsdbutil as root from within a script that is not run as root.

[Detrius]

Ummm... You could learn Cocoa.

Or, you could run the script as root and use su to run the other stuff as someone else.

Check out the man page for 'su'. Specifically, check out the -c option.

sudo su auser -c tcsh

launches tcsh as auser.

[[APi]TheMan]

Originally posted by Detrius:
Ummm... You could learn Cocoa.

Or, you could run the script as root and use su to run the other stuff as someone else.

Check out the man page for 'su'. Specifically, check out the -c option.

sudo su auser -c tcsh

launches tcsh as auser.

That might work, kinda a pain in the butt, though. I'm no good with GUI coding, but what about prompting the user for a password, and then passing that to your shell script? If you use the "-S" option sudo will read the password from standard input, example:

Code:
[theman@nacho: ~]$ ls /var/root/
ls: /var/root/: Permission denied
[theman@nacho: ~]$ echo "password" | sudo -S ls -a /var/root
.   .CFUserTextEncoding  .forward  .profile  Library
..  .bash_history        .nsmbrc   .viminfo

[utidjian]

Originally posted by [APi]TheMan:
That might work, kinda a pain in the butt, though. I'm no good with GUI coding, but what about prompting the user for a password, and then passing that to your shell script? If you use the "-S" option sudo will read the password from standard input, example:

Code:
[theman@nacho: ~]$ ls /var/root/
ls: /var/root/: Permission denied
[theman@nacho: ~]$ echo "password" | sudo -S ls -a /var/root
.   .CFUserTextEncoding  .forward  .profile  Library
..  .bash_history        .nsmbrc   .viminfo

Which would also be a good time to zero out theman's .bash_history file.

[Gavin]

'The bottom line is that disabling "Ignore ownership" makes rsync smarter and faster,'

the sent up a flag with me.

It sounds like you're going for a hacked workaround when you should really figure out what's gong on with rsync which is where the trouble really lies.

rsync should be able to deal with everything in your home folder without need for sudo or root access. Evidently it isn't, but the last thing I'd do is turn off security just to get past a bug.

What does your rsync command look like?

Are you trying to back up files your user doesn't own?

What kind of app is it? applescript, cocoa app, shell script?

What's the fastest animal?

Setting some part to run as root, possible but a pain to set up, just sets off a domino line of bad juju. A search for setuid turns up more warnings not to mess with it than info on how to use it.

[wataru]

Um, read what I wrote again. Disabling "Ignore ownership" is what I want to do. Yes, I know that's a confusing double negative, but that's what Apple calls it. In other words, I want ownership to be enabled. Without ownership, it looks like rsync can't figure out what's newer than what, or something like that.

Everything is explained at the link I provided before, but just a quick overview: The app is based on a bash script. It backs up items in one's home folder, so I imagine the user owns all of the files in question.

Again: I am not trying to run rsync as root. I need to run vsdbutil as root so I can enable ownership on the target disk.

Well, I guess I can just settle for bugging the user, since you don't need to run it as root to check the state of permissions.

[[APi]TheMan]

Originally posted by wataru:
Well, I guess I can just settle for bugging the user, since you don't need to run it as root to check the state of permissions.

Yeah yeah, passing a parameter to a shell script and using sudo -S sounds good to me.

[Angus_D]

Hmm... Would anybody like an "authdo" command? I could probably cobble one together quite easily. Like sudo but using Authorization Services to do stuff.

[[APi]TheMan]

Originally posted by Angus_D:
Hmm... Would anybody like an "authdo" command? I could probably cobble one together quite easily. Like sudo but using Authorization Services to do stuff.

That sounds interesting. So instead of looking at /etc/sudoers to see if a user is privileged or not you'd be using Authorization Services (presumably from the Netinfo database, no?)?

Sounds cool.

[Angus_D]

Originally posted by [APi]TheMan:
That sounds interesting. So instead of looking at /etc/sudoers to see if a user is privileged or not you'd be using Authorization Services (presumably from the Netinfo database, no?)?

sudo consults NetInfo indirectly, but it doesn't authenticate via the GUI.

Although to be honest I don't see what you'd gain but typing your password into a window provided by SecurityAgent vs a prompt in a Terminal window.

[Gavin]

Originally posted by wataru:

Again: I am not trying to run rsync as root. I need to run vsdbutil as root so I can enable ownership on the target disk.

I get that. My point is that vsdbutil as root strikes me as overkill for a simple backup script. There might be a different tack that produces results.

So your problem is that the filesystem itself is ignoring the file ownership.

The 'Ignore ownership on this volume' checkbox that's screwing things up looks like a hack for OS 9 compatibility. So what you're really trying to do is be nice and turn it off for them. As they probly don't want that checked anyway if their home folder in there, I would instruct users to turn that off manually, then you should be good to go.

I think there's an ethical issue here. I'd consider it bad policy to change the settings on someone else's filesystem. It might have unintended consequences. For instance you might be pissed if some script turned off journaling without telling you. It might even break something if file sharing is running, who knows.

I'd tell the user what the deal is and have them make an informed decision to turn it off themselves if they want to.


I know rsync has trouble with HFS+. There is a patched version out there that might have better luck with 'Ignore ownership'. I would assume that Xrsync would supply the patched version but it's worth double checking that that's what you're running.

http://www.quesera.com/reynhout/misc/rsync+hfsmode/


Have fun.

[[APi]TheMan]

Originally posted by Angus_D:
sudo consults NetInfo indirectly, but it doesn't authenticate via the GUI.

So how does /etc/sudoers do its dirty work? I use the sudoers file to lock down lots of my machines, which works beautifully. I usually remove the admin group from the sudoers file and explicitly allow users/privileges. The user is still in the admin group as far as Netinfo goes, though... Is sudoers just a secondary tier in the authentication process (Check the Netinfo database to see what groups the user is in and then check the sudoers file to see who's allowed to use sudo?

Thanks

[wataru]

Originally posted by Gavin:
I'd tell the user what the deal is and have them make an informed decision to turn it off themselves if they want to.

I know rsync has trouble with HFS+. There is a patched version out there that might have better luck with 'Ignore ownership'. I would assume that Xrsync would supply the patched version but it's worth double checking that that's what you're running.

http://www.quesera.com/reynhout/misc/rsync+hfsmode/


Have fun.

Yeah, at this point I'm just settling for bugging the user about it, with an option never to be bugged again.

I checked out that link, and at one point the author says that RsyncX's version works fine as long as the destination is also HFS+. That is the case with my app, so I'm assuming that switching to a different version of rsync would not help.

Thanks, guys.

[Angus_D]

Originally posted by [APi]TheMan:
So how does /etc/sudoers do its dirty work? I use the sudoers file to lock down lots of my machines, which works beautifully. I usually remove the admin group from the sudoers file and explicitly allow users/privileges. The user is still in the admin group as far as Netinfo goes, though... Is sudoers just a secondary tier in the authentication process (Check the Netinfo database to see what groups the user is in and then check the sudoers file to see who's allowed to use sudo?

No, sudoers defines who is allowed to use sudo. I don't know what you're on about with tiers and stuff, or "dirty work"...

However, if they're in admin they'll still be able to execute arbitrary commands as root - see /etc/authorization (used by Authorization Services).

[[APi]TheMan]

Originally posted by Angus_D:
No, sudoers defines who is allowed to use sudo. I don't know what you're on about with tiers and stuff, or "dirty work"...

However, if they're in admin they'll still be able to execute arbitrary commands as root - see /etc/authorization (used by Authorization Services).

I guess I was seeing the several authorities incorrectly. That said, /etc/authorization is confusing to me but from looking at the file I see that it controls privileges of certain users/groups for various tasks (installing as admin, burning media, editing keychains, etc) and other stipulations of authenticated tasks.

Thanks for the hints, I'll have look into that stuff a little more...