sudo shell command?

I am writing some shell script for the shell to execute.
I run the script from the terminal with sudo as it requires root privileges.
$ sudo ./myscript

myShell.mode = 1
myShell.Exec(“sudo ./myscript”)

I get the shell completed event immediately and the scripts commands are not executed and there is nothing in the shell results.

I figured that that made sense maybe this should have been done in mode=2 and I should be looking for DataAvailable event to fire with “Password:” and I would write the password to the shell. but no…

So I wondered what if I launched myApplication using sudo
$sudo MyApplication

Then maybe I wouldn’t need to use the sudo in the “sudo ./myscript” as any process I invoke from myApplication should also run with root privileges to shouldn’t it?

confused…

Google “authorizationShell realbasic”, there should be a both a MBS and a declares-based solution to be found.
You’d use it in place of Xojo’s Shell class, to launch a command as root, with the system asking the user to input his login. You can even supply the login password yourself. But that goes a bit deeper. Maybe I’ll write a blog post about it one day.

If you know the root password for the machine your app is running on, you can try this:

Dim My_Shell As New Shell My_Shell.Execute "echo YourRootPassword | sudo -S /YourPath/YourExecutable" MsgBox My_Shell.Result

It works on Ubuntu, which I should have indicated. Brian didn’t specify whether he was running OS X or Linux. For OS X he’ll need one of the solutions you suggested.

Yes, I was wrong in my comment - I had been to hasty and tested your suggestion incorrectly. That’s why I had deleted it soon after.
Your suggestion works on OSX.

[quote=34841:@Thomas Tempelmann]Yes, I was wrong in my comment - I had been to hasty and tested your suggestion incorrectly. That’s why I had deleted it soon after.
Your suggestion works on OSX.[/quote]
That’s good to know. Thanks for passing it along. I’ve only used it on Ubuntu.

Using echo to pass the password is a bad practice. The password may show up in plain text on the process list or elsewhere.

I wrote a Sudo Shell subclass, if anyone is interested. It uses Interactive to pass the password to sudo. I’ve tested it on Mac, Windows, and Ubuntu (an older version), but it’s an open class so it can be customized or fixed as needed.

[quote=34891:@Kem Tekinay]Using echo to pass the password is a bad practice. The password may show up in plain text on the process list or elsewhere.

I wrote a Sudo Shell subclass, if anyone is interested. It uses Interactive to pass the password to sudo. I’ve tested it on Mac, Windows, and Ubuntu (an older version), but it’s an open class so it can be customized or fixed as needed.[/quote]
That’s a good point. Thanks Kem. Consider me interested in your Sudo Shell subclass. I imagine that there are others that would find it useful too, especially since it’s cross-platform.

See here:

http://www.mactechnologies.com/public_files/SudoShell/SudoShell.zip

I’ll officially put this up on my web site eventually.

Thanks Kem. But I still get failed…

Does the example project work for you?

I think I know what’s wrong Kem. My system seems to log some errors before it spews out the Passord: prompt… I think that may be confusing the class in that is expects a clean Password: string.

Nope… It just doesn’t work… but thanks Kem.

I haven’t looked in a while but I thought I built it to ask a subclass to deal with unknown strings.

Just a warning about Kem’s SudoShell: It is in the same way dangerous as the one from Frederick is: It requires that the app has to ask the user for the password. Which means that the app will know the user’s password. And that’s a security risk, in several ways:

  1. I, as the user, may not like it that an app knows my password, as it could then secretly “call home”, telling the app’s maker my pw so that he can later break into my computer.
  2. Similarly, other programs could find easy ways to hack or monitor this app to learn the pw and abuse it.

That’s why I recommend using the AuthorizationShell instead: That one uses OSX’s standard authentication dialog that everyone gets to see when using a program that needs root permissions. Even though that function also asks the user for his login, the information stays private in OSX, and Apple has taken care of making sure that the pw won’t end up in log files or other hackable ways, and the program that calls this AuthorizationShell will not get to see the pw, either.
Additionally, this allows the user to enter another user’s login credential in case that the current user is not an admin and therefore has no root elevation rights.

So, at least on OSX, I suggest you use AuthorizationShell. On Win + Linux, I do not know similar solutions, so you might want to use Kem’s solution there if you find no other option.

I can’t argue with any of that. My class is fine for private (or limited) use, but for a commercial app, I wouldn’t use it on a Mac.

However, small clarification: My class will optionally use the -u switch if an alternate username is given.

[quote=34833:@Thomas Tempelmann]Google “authorizationShell realbasic”, there should be a both a MBS and a declares-based solution to be found.
You’d use it in place of Xojo’s Shell class, to launch a command as root, with the system asking the user to input his login. You can even supply the login password yourself. But that goes a bit deeper. Maybe I’ll write a blog post about it one day.[/quote]
Careful as I believe Apple has deprecated the calls used in the AuthorizationShell

So what is the best solution for OS X? And how about Windows and Linux?

Not only this, but this solution doesn’t work in some very specific scenarios and it’s pretty hard to figure out why. The best one is handling Launchctl. For Launchctl in OS X you need to have an authorised shell launch a setuid’d helper app.

In the helper run event:

Soft Declare Function setuid Lib "/usr/lib/libc.dylib" (uid As Integer) As Integer Dim setuid_result As Integer = setuid(0) If setuid_result = -1 Then Print "ERROR-setuid failed." Return 1 End If
Shell commands after this will be done as root. But this helper needs to be launched by an authorized admin action, which prompts the user for a password using the system prompt (and the app never sees the password). The AuthorizationShell class I use in OS X does this with the AuthorizationExecuteWithPrivileges system call and then removes the authorization when done.

As Norman says, the call has been deprecated and SMJobBless should be used now, but I don’t have nor have I seen an implementation of it for OS X yet.

This StackOverflow question explains it a bit better without going into much detail. I’d love to see an implementation in Xojo, though.

Actually, I’d love for Xojo to natively support raising calls to admin contexts built-in, with them managing the x-platform differences, but I wonder if that makes sense nowadays when whole operating systems are moving away from letting apps get admin privileges (like OS X)

Yes, AuthorizationShell is deprecated, it doesn’t mean that it can’t be used any more right now. Apple just has provided a new and cleaner way that should be used instead, but it’s much harder to use that with Xojo, so I recommend using AuthorizationShell.

Also, Eduardo’s suggestion is MUCH worse: Apple warns against using setuid apps, because they’re a huge security risk as it allows you to create apps that permanently run as root without the control of the user, by anyone. Apps with setuid 0 must be protected very carefully, e.g. they may make sense in an installer that is only temporarily available, but should not exist anywhere on the boot disk as there are many tricks to use them for root elevation hacks.

If you have software that needs to run with root permissions every time the user logs in, then the proper way (instead of setuid) is to use the LaunchAgent/LaunchDaemon system.