FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 09-12-2010, 09:59 PM
Rob Owens
 
Default Updating files in /etc Remotely (and automated)

On Sun, Sep 12, 2010 at 10:58:22PM +0100, Steve Kemp wrote:
> On Sun Sep 12, 2010 at 16:24:59 -0400, Rob Owens wrote:
>
> > If you run "sudo somescript", then the script runs as root, so every
> > command inside it will run as root.
> > I think it is generally considered smarter, security-wise, to
> > run "somescript" and then include "sudo" inside the script as
> > necessary.
>
> I believe that makes sense in an objective way, but I've never
> seen that defined as a "best practise", and your example fails
> in a way that suggests you've not done it that way yourself.
>
>
> > sudo ls /root/*
>
> Fails. Why? Because _your_ shell does the expansion, before
> passing to sudo.
>
> For example compare these two command and outputs:
>
> skx@birthday:~$ sudo ls /root/*
> skx@birthday:~$
> skx@birthday:~$ sudo ls /root/
> Desktop
> skx@birthday:~$
>

Correct, I didn't test that script myself. It was intended as an
example to clarify my explanation.

Regarding best practice:

If you run your entire script as root, then you introduce the
possibility that someone could cause your script to crash in such a way
that it gives the attacker root access. How? I'm not sure, but if you
run the script as a regular user you can avoid the possibility that
somebody else figures out how.

I'd say it's probably analagous to running services as a non-privileged
user. It's best to do it if you can, because it removes a lot of "what
if" scenarios.

-Rob


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100912215900.GA32755@aurora.owens.net">http://lists.debian.org/20100912215900.GA32755@aurora.owens.net
 
Old 09-12-2010, 10:04 PM
Joe
 
Default Updating files in /etc Remotely (and automated)

On 12/09/10 21:24, Rob Owens wrote:

On Sun, Sep 12, 2010 at 02:35:00PM -0400, Hal Vaughan wrote:


On Sep 12, 2010, at 12:37 PM, Rob Owens wrote:

...

When using ssh keys to log in, you can specify (in
~/.ssh/authorized_keys) a command which will automatically run when that
key is used to log in. And that key will be useless to do anything
else. Simply using that key to conenct to the remote server will run
that command.

The authorized_keys file would look something like this:

command="/path/to/my/script" ssh-rsa AAAAB3NzaC1yc2EAAA.... me@myhost


I see. That would make perfect sense and I see I can use -i to specify which key to use, so for normal situations, I just use "ssh host," and when I want this done, I do "ssh -i .ssh/special_key host" instead.

I thought I knew about authorized keys, but didn't know you could specify a command to be run in that file.


You could use this to ssh into the remote server as root, or as a user
with very specify sudo privileges that will allow your script to run.
(The script would perform the file changes you need done, or simply
rsync them from your local machine).


But if I'm not running as root, from what I can see, no matter what I do with sudo, I still have to type in a password, don't I? using the authorized_keys file and specifying what can be done at login does a lot to help with security, but if I don't log in as root, no matter what I do, I'll still have to type in a password to use either "su" or "sudo," right? Or is there a way around it? I was going through man pages, but it seems both require a password to be typed in no matter what.


In /etc/sudoers, you can specify "NOPASSWD", like this:

someuser ALL=NOPASSWD: /path/to/some/command

Then "someuser" can run the specified command as root without typing a
password.


When I tested this with some simple scripts, I find if I create a batch file that runs a few commands, like "chown root:root filename" that those commands, which would normally need the sudo command don't need it.

Is this because of the (usually) 5 minute time limit sudo uses? Can I trust this on all systems, or is there anything that could prevent this behavior? In other words, if I include, in the script, commands that also need sudo, am I right that I can count on them executing without further need of verification?



If you run "sudo somescript", then the script runs as root, so every
command inside it will run as root. I think it is generally considered
smarter, security-wise, to run "somescript" and then include "sudo"
inside the script as necessary. For instance, your script might look
like this:

#!/bin/bash
#
# myscript.sh
#
sudo ls /root/*
ls /home/* #doesn't need root privileges
sudo touch /usr/local/somefile

This script could be run as a regular user, but it would only run
properly if the user had the appropriate sudo rights.



Note that sudo does not completely mimic root behaviour. Commands using
>, and presumably other composite commands, will depend on the user's
own permissions.


In an 'all-root' directory, with no existing file2:

sudo cp file1 file2 works as expected
sudo touch file2 works as expected
sudo cat file1 works as expected
sudo cat file1 > file2 fails due to lack of write permission
su -c "cat file1 > file2", then <password>, works as expected

It isn't just cat, I first noticed this some years ago with aggregate,
which also uses >. I assume that when the shell reaches the >, which is
effectively another command, the temporary sudo one-command permission
has expired. The trick with the quotation marks doesn't work, sudo
expects the entire quoted string to be the name of an executable.


--
Joe


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4C8D4E6B.7010803@jretrading.com">http://lists.debian.org/4C8D4E6B.7010803@jretrading.com
 
Old 09-12-2010, 11:47 PM
Eduardo M KALINOWSKI
 
Default Updating files in /etc Remotely (and automated)

On 09/12/2010 07:04 PM, Joe wrote:

Note that sudo does not completely mimic root behaviour. Commands using
>, and presumably other composite commands, will depend on the user's
own permissions.

In an 'all-root' directory, with no existing file2:

sudo cp file1 file2 works as expected
sudo touch file2 works as expected
sudo cat file1 works as expected
sudo cat file1> file2 fails due to lack of write permission
su -c "cat file1> file2", then<password>, works as expected

It isn't just cat, I first noticed this some years ago with aggregate,
which also uses>. I assume that when the shell reaches the>, which is
effectively another command, the temporary sudo one-command permission
has expired. The trick with the quotation marks doesn't work, sudo
expects the entire quoted string to be the name of an executable.


Actually, the shell (running as the normal user) sees the redirection,
tries to opens the file, and then runs "sudo cat file1", redirecting the
output to the opened file. Then sudo runs, cat'ing the file (as root) to
stdout.



--
Do YOU have redeeming social value?

Eduardo M KALINOWSKI
eduardo@kalinowski.com.br


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4C8D667B.1070000@kalinowski.com.br">http://lists.debian.org/4C8D667B.1070000@kalinowski.com.br
 
Old 09-13-2010, 12:56 PM
"Jesús M. Navarro"
 
Default Updating files in /etc Remotely (and automated)

Hi, Hal:

On Saturday 11 September 2010 23:15:50 Hal Vaughan wrote:
> I will be working with a server on the Internet that uses rsync and is
> running Debian. I will be setting up initial /etc/rsyncd.conf and
> /etc/rsyncd.secrets files on it. But along the way, whenever a new user is
> added, they'll need to be updated. I can use ssh on this system, but, of
> course, I don't want to allow root access.
>
> I'd like to be able to have these files updated automatically when I add a
> new user to another system. I could create new copies of the files
> locally, where the users are added and use scp to copy them to a directory
> on the server. But that's where there are problems. How can I chown the
> files to root, copy them to /etc, and chmod as needed for rsync to use them
> automatically?

I know that's not what you specifically asked for, but thinking a bit
out-of-the-box, what you have is a need to remotely configure a machine from
a "central" information repository.

Have you though about using Puppet*1 for that?

*1 http://www.puppetlabs.com

Cheers.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201009131456.15818.jesus.navarro@undominio.net">ht tp://lists.debian.org/201009131456.15818.jesus.navarro@undominio.net
 
Old 09-17-2010, 04:17 AM
T o n g
 
Default Updating files in /etc Remotely (and automated)

On Sun, 12 Sep 2010 14:31:12 -0400, Hal Vaughan wrote:

> . . . someone sent it to me
> privately a little while ago. While I like what Rob Owens suggested,
> I'm leaning toward this. I think it's possible that I could send up the
> minimum information in a file and have the cron job be a Perl script
> that takes that info and builds the rsyncd.conf and rsyncd.secrets files
> from there, which reduces the possibility of a rogue file being copied
> over somehow. Still, none of the ideas is perfect, but putting together
> the conf files on the site, as opposed to sending them directly, has
> certain merits.

Could you post back your chosen solution please?

I was looking for solutions for the same situation.

Thanks

--
Tong (remove underscore(s) to reply)
http://xpt.sourceforge.net/techdocs/
http://xpt.sourceforge.net/tools/


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: i6uq5l$478$1@dough.gmane.org">http://lists.debian.org/i6uq5l$478$1@dough.gmane.org
 
Old 09-17-2010, 11:26 AM
"B. Alexander"
 
Default Updating files in /etc Remotely (and automated)

I agree with Jesús. This is a far more elegant and scalable solution, though my experience is with cfengine [1]. This allows you to use svn or cvs to manage the master files, check out the files to your workstation, make changes and commit, and depending on how you have it set up, have the changes automatically propagated. There are actually several similar packages (cfengine => perl-ish, bcfg2 => python-ish, puppet => ruby-on-rails-ish, etc.) They all have the same goal in mind, convergence of system configurations, loosely referred to as configuration management.


--b

[1] http://www.cfengine.org

2010/9/13 Jesús M. Navarro <jesus.navarro@undominio.net>

Hi, Hal:



On Saturday 11 September 2010 23:15:50 Hal Vaughan wrote:

> I will be working with a server on the Internet that uses rsync and is

> running Debian. *I will be setting up initial /etc/rsyncd.conf and

> /etc/rsyncd.secrets files on it. *But along the way, whenever a new user is

> added, they'll need to be updated. *I can use ssh on this system, but, of

> course, I don't want to allow root access.

>

> I'd like to be able to have these files updated automatically when I add a

> new user to another system. *I could create new copies of the files

> locally, where the users are added and use scp to copy them to a directory

> on the server. *But that's where there are problems. *How can I chown the

> files to root, copy them to /etc, and chmod as needed for rsync to use them

> automatically?



I know that's not what you specifically asked for, but thinking a bit

out-of-the-box, what you have is a need to remotely configure a machine from

a "central" information repository.



Have you though about using Puppet*1 for that?



*1 http://www.puppetlabs.com



Cheers.





--

To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org

with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: http://lists.debian.org/201009131456.15818.jesus.navarro@undominio.net
 

Thread Tools




All times are GMT. The time now is 01:52 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org