Forum: Ruby executing sudo from ruby

hi,
I wanna execute in a script of mine commands like: "sudo apt-get clean"
or "sudo nano /etc/X11/xorg.conf". The difference is:

The first command needs to be executed without influence to the main
process of the ruby scipt. It should simply be started as a second
process totally independent from the ruby-script which invokes it.
I think system("sudo apt-get clean") would be the right command.

The second command should be this way that it is the only one after it
has been executed. So the ruby-script should be stopped and therefor in
the same console nano should be opened.
I think exec("sudo nano /etc/X11/xorg.conf") would be the right command.

But my problem is the password of sudo? How can I make my ruby-scipt
give the password to sudo so I don't have to give it in every time?


--
greets

                     one must still have chaos in oneself to be able to
give birth to a dancing star

Hardcoding passwords is a very, very, very, very bad idea.

If you really need to do this - and it's very likely that there's a 
better,
safer way to do it, but there's not enough information given on what 
you're
actually trying to achieve - read up on sudo and how you can use its
configuration files to grant users or groups the ability to run 
particular,
selected commands via sudo without requiring a password.

"man sudoers" should be a pretty good start.

anansi wrote:
> has been executed. So the ruby-script should be stopped and therefor in 
> the same console nano should be opened.
> I think exec("sudo nano /etc/X11/xorg.conf") would be the right command.
> 
> But my problem is the password of sudo? How can I make my ruby-scipt 
> give the password to sudo so I don't have to give it in every time?
> 
> 

Set NOPASSWD in your sudoers file for the given commands, eg.:

sudoeruser ALL=(ALL) NOPASSWD: /usr/bin/nano,/usr/bin/apt-get


Morten

thanks for your answers but that are no options here. I know hardcoded
passes are in generally a bad idea but it's really needed here and safe.
This is just a personal code on an offline pc with a highly encrypted
partitions...

Is there no way to give the pass as argument or pipe it or kind if that?
But as said I need a technique working in both cases mentioned in the
first post.

Morten wrote:
>> The second command should be this way that it is the only one after it 
> 
> sudoeruser ALL=(ALL) NOPASSWD: /usr/bin/nano,/usr/bin/apt-get
> 
> 
> Morten


--
greets

                     one must still have chaos in oneself to be able to
give birth to a dancing star

On 6/13/07, anansi <kazaam@oleco.net> wrote:
> The second command should be this way that it is the only one after it
> has been executed. So the ruby-script should be stopped and therefor in
> the same console nano should be opened.
> I think exec("sudo nano /etc/X11/xorg.conf") would be the right command.
>
> But my problem is the password of sudo? How can I make my ruby-scipt
> give the password to sudo so I don't have to give it in every time?



I am not so clear on what you are asking here, but you can perhaps give 
a
password to sudo via stdin.
Here's a line from "man sudo":
 -S  The -S (stdin) option causes sudo to read the password from the
standard input instead of the terminal device.

To open a pipe to a subprocess, see IO.popen, example near the bottom of
this page:
http://www.rubycentral.com/book/tut_threads.html

I can't comment on the safety of doing this, but it's surely not the 
worst
way to send a password.


Les


--

anansi wrote:
> has been executed. So the ruby-script should be stopped and therefor in 
> the same console nano should be opened.
> I think exec("sudo nano /etc/X11/xorg.conf") would be the right command.
> 
> But my problem is the password of sudo? How can I make my ruby-scipt 
> give the password to sudo so I don't have to give it in every time?
> 
> 
Wouldn't a setuid root script that actually calls the executable you're
aiming at do what you need here?

the thing is that everything needs to be done by this script and no
further command. So can an app give it self the root uid at runtime?

Alex Young wrote:
>> The second command should be this way that it is the only one after it 
> 
--
greets

                     one must still have chaos in oneself to be able to
give birth to a dancing star

anansi wrote:
> the thing is that everything needs to be done by this script and no 
> further command. So can an app give it self the root uid at runtime?
After a little experimentation (on Ubuntu), it would seem that the only
way to get my suggestion to work is by creating a setuid link to the
ruby binary, and using that to run the script.  That's just as insecure
as keeping a password in a file, so I take back my suggestion entirely.

A slightly less unsafe method (but still rather iffy) would be to create
a public key for the root account, and do everything over SSH.  That way
you can arrange to only need to authenticate once per session (or, if
you really want to play fast and loose, leave the private key with an
empty passphrase).  I don't know if that helps at all...

--
Alex

On 13-Jun-07, at 8:40 AM, anansi wrote:

> the thing is that everything needs to be done by this script and no  
> further command. So can an app give it self the root uid at runtime?

If you aren't worried about security, you might try expect. Using
expect you can define responses to prompts, e.g. responding with the
password.

----
Bob Hutchison                  -- tumblelog at <http://
www.recursive.ca/so/>
Recursive Design Inc.          -- weblog at <http://www.recursive.ca/
hutch>
                                -- works at <http://www.recursive.ca/>

On Wed, 13 Jun 2007 22:19:16 +0900, Alex Young wrote:

> you can arrange to only need to authenticate once per session (or, if
> you really want to play fast and loose, leave the private key with an
> empty passphrase).  I don't know if that helps at all...

To run your editor, you'd probably need to use the -t option of ssh to
alloate a pseudo-tty.

You can configure the SSH keypair so that it's only authorized to run a
couple of specific commands, which should help with security. Also, be
sure to use "nano -R" so that the user can't edit other files.

The exec() call is wrong, because that replaces the running ruby script
with a different process, and the ruby script can't terminate. system()
is correct for the second case too.

thanks for the hint but I only found this about
expect:http://www.ruby-doc.org/stdlib/libdoc/pty/rdoc/cla...

. Is there any better doc or examples for this ?


--
greets

                     one must still have chaos in oneself to be able to
give birth to a dancing star

On 13-Jun-07, at 12:35 PM, anansi wrote:

> thanks for the hint but I only found this about expect:http:// 
> www.ruby-doc.org/stdlib/libdoc/pty/rdoc/classes/IO.html#M001710
> . Is there any better doc or examples for this ?

I used the unix version of the command directly. The man page is
useful I thought. I've never used the ruby expect classes but imagine
that they would be doing something similar.

Cheers,
Bob

>
>
> -- 
> greets
>
>                     one must still have chaos in oneself to be able  
> to give birth to a dancing star
>

----
Bob Hutchison                  -- tumblelog at <http://
www.recursive.ca/so/>
Recursive Design Inc.          -- weblog at <http://www.recursive.ca/
hutch>
                                -- works at <http://www.recursive.ca/>

Alex Young wrote:
> anansi wrote:
>> the thing is that everything needs to be done by this script and no 
>> further command. So can an app give it self the root uid at runtime?
> After a little experimentation (on Ubuntu), it would seem that the only
> way to get my suggestion to work is by creating a setuid link to the
> ruby binary, and using that to run the script.  That's just as insecure
> as keeping a password in a file, so I take back my suggestion entirely.
> 
> A slightly less unsafe method (but still rather iffy) would be to create
> a public key for the root account, and do everything over SSH.  That way
> you can arrange to only need to authenticate once per session (or, if
> you really want to play fast and loose, leave the private key with an
> empty passphrase).  I don't know if that helps at all...
> 
> --
> Alex

How about running job in a cron under root user.

sudo kcron (in kde) will start kcron in mode where you can schedule a 
job to run as any user.

by

TheR