LinuxQuestions.org - [SOLVED] having problem chown-ing a file so the cron runs it as its own user

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - having problem chown-ing a file so the cron runs it as its own user (https://www.linuxquestions.org/questions/linux-newbie-8/having-problem-chown-ing-a-file-so-the-cron-runs-it-as-its-own-user-747892/)

having problem chown-ing a file so the cron runs it as its own user

For security, I am changing some of the running cron scripts so they run as user:dbscripts instead of the root user.
This should hopefully lock down their permissions.

The following script runs a daily backup and FTP's it to a server.
It is set to tar the file into the following directory:
drwxr-xr-x 2 root root 4096 Aug 16 02:31 myscripts

So, I chown the entire folder to dbscripts and 777 it.
drwxrwxrwx 2 dbscripts dbscripts 4096 Aug 16 02:31 myscripts

I then login as dbscripts and run the daily backup:
-rwxrwxr-x 1 dbscripts dbscripts 347 Aug 16 02:04 dailybackup.sh

However, I get a permission denied on the folder but the rest of the FTP runs correctly:

Code:

[root@localhost myscripts]# su dbscripts

[dbscripts@localhost myscripts]$ ./dailybackup.sh

/bin/tar: /etc/myscripts/backup-16082009.tar.gz: Cannot open: Permission denied

/bin/tar: Removing leading `/' from member names

/bin/tar: Error is not recoverable: exiting now

Connected to ftp.mysite.com.

220 Servage FTP4

500 AUTH not understood

500 AUTH not understood

KERBEROS_V4 rejected as an authentication type

Remote system type is UNIX.

Using binary mode to transfer files.

Local directory now /etc/myscripts

331 Password required for username

230 User usernamelogged in

local: backup-16082009.tar.gz remote: backup-16082009.tar.gz

227 Entering Passive Mode.

150 Opening BINARY mode data connection for backup-16082009.tar.gz

226 Transfer complete

10903389 bytes sent in 8.1 seconds (1.3e+03 Kbytes/s)

221 Goodbye.

[dbscripts@localhost myscripts]$

Quote:

Originally Posted by qwertyjjj (Post 3645136)

For security, I am changing some of the running cron scripts so they run as user:dbscripts instead of the root user. This should hopefully lock down their permissions.

You got this advice from where?

Quote:

Originally Posted by qwertyjjj (Post 3645136)

(..) I then login as dbscripts and run the daily backup

If you want to run a cronjob as unprivileged user then edit the crontab of that user account.

Quote:

Originally Posted by qwertyjjj (Post 3645136)

(..) I chown the entire folder to dbscripts and 777 it. (..) /bin/tar: /etc/myscripts/backup-16082009.tar.gz: Cannot open: Permission denied

/etc is owned by user root and group root and has only read rights for other. Chowning it is really, really bad. Restore the permissions before doing anything else, then move the myscripts/ directory to the unprivileged users home or a partition you use for storing backups. Discretionary access permissions are there for a reason. As I said before, and this is the last time I'll mention it, do read the docs that come with Centos and generic UNIX tutorials like Rute.

Quote:

Originally Posted by unSpawn (Post 3645303)

You got this advice from where?

This: http://www.linuxquestions.org/questi...41#post3643841

Is it okay to run these scripts as root from the crontab then?
One of scripts that runs is a PHP script with exec command in there.
I have escaped the input with escapeshellcmd but if it's running as root and someone manages to put an SQL in jection attack into the remote database then it could cause issues?

Quote:

If you want to run a cronjob as unprivileged user then edit the crontab of that user account.

/etc is owned by user root and group root and has only read rights for other. Chowning it is really, really bad. Restore the permissions before doing anything else, then move the myscripts/ directory to the unprivileged users home or a partition you use for storing backups. Discretionary access permissions are there for a reason. As I said before, and this is the last time I'll mention it, do read the docs that come with Centos and generic UNIX tutorials like Rute.

I am reading them but I need to get the server up and running at the same time :)
The centOS docs did look more like server architecture than permissions stuff (http://www.centos.org/docs/5/). I need a rute for RHEL
So, do I need to change the user running from crontab?
If so, I:
- create a user
- copy all the scripts to the new directory
- chown that directory to the new user

When I do that the script won't run as it seems the new user does not have access to read:

Code:

/bin/tar: Removing leading `/' from member names

/bin/tar: /etc/sysconfig/auditd: Cannot open: Permission denied

/bin/tar: /etc/sysconfig/ip6tables-config: Cannot open: Permission denied

/bin/tar: /etc/sysconfig/named: Cannot open: Permission denied

/bin/tar: /etc/sysconfig/ip6tables: Cannot open: Permission denied

/bin/tar: /etc/sysconfig/rkhunter: Cannot open: Permission denied

/bin/tar: /etc/sysconfig/.iptables.swo: Cannot open: Permission denied

/bin/tar: /etc/sysconfig/iptables.save: Cannot open: Permission denied

/bin/tar: /etc/sysconfig/iptables: Cannot open: Permission denied

/bin/tar: /etc/default/useradd: Cannot open: Permission denied

/bin/tar: /etc/cups/printers.conf: Cannot open: Permission denied

/bin/tar: /etc/cups/cupsd.conf.default: Cannot open: Permission denied

/bin/tar: /etc/cups/classes.conf: Cannot open: Permission denied

/bin/tar: /etc/cups/cupsd.conf: Cannot open: Permission denied

/bin/tar: /etc/cups/ssl: Cannot savedir: Permission denied

/bin/tar: /etc/audit: Cannot savedir: Permission denied

/bin/tar: /etc/shadow: Cannot open: Permission denied

/bin/tar: /etc/matrixsa: Cannot savedir: Permission denied

/bin/tar: /etc/mgetty+sendfax/dialin.config: Cannot open: Permission denied

I can't add the newuser to the root group as that will give them all the same permissions?

Quote:

Originally Posted by qwertyjjj (Post 3645311)

Is it okay to run these scripts as root from the crontab then?

As you've found out making a system backup needs root privileges, hence it must run as root. Adding a user to the root group is not a good practice.

Quote:

Originally Posted by qwertyjjj (Post 3645311)

One of scripts that runs is a PHP script with exec command in there. I have escaped the input with escapeshellcmd but if it's running as root and someone manages to put an SQL in jection attack into the remote database then it could cause issues?

The URI you posted doesn't handle system backups (topic) so questions about that topic should be posted there, not here. Please don't take a reply as an invitation to mix up questions and threads, it will become very inefficient very soon and of no use to those reading the threads afterwards.

Quote:

Originally Posted by unSpawn (Post 3645361)

As you've found out making a system backup needs root privileges, hence it must run as root. Adding a user to the root group is not a good practice.

Ok, but if I copy all the scripts to the /home directory of the new user and chown them, I would have to leave this one script as chowned by root?
Because if the permissions are 775 on the file, then only newuser and the newuser group will be able to execute it.

It is best to keep scripts owned by root in a location in line with the FSSTND / FHS / LSB (or whatever other system layout standard is current). Scripts that are system cronjobs go in the various /etc/cron\..* dirs, local additions go in /usr/local, so shell scripts that are run manually by root (not executed by unprivileged users) could be in /usr/local/sbin with octal mode 0750.

Quote:

Originally Posted by qwertyjjj (Post 3645367)

you can give the unprivileged user sudo access, so they can just run certain commands they would not otherwise have access to unless specified in /etc/sudoers.
there are some examples in the /etc/sudoers file.

Quote:

Originally Posted by centosboy (Post 3645519)

Nope, not quite there yet. Output from the script

Code:

[dbscripts@localhost myscripts]$ ./add_remove_squid_users.php

Adding password for user joebloggs

/usr/bin/htpasswd: unable to update file /etc/squid/squid_passwd

[dbscripts@localhost myscripts]$

sudoers exceptions added:

Code:

User_Alias PROXYACCESS = dbscripts

Cmnd_Alias PROXYACCESS = /etc/squid/squid_passwd

Quote:

Originally Posted by qwertyjjj (Post 3645550)

Nope, not quite there yet. Output from the script

Code:

[dbscripts@localhost myscripts]$ ./add_remove_squid_users.php

Adding password for user joebloggs

/usr/bin/htpasswd: unable to update file /etc/squid/squid_passwd

[dbscripts@localhost myscripts]$

sudoers exceptions added:

Code:

User_Alias PROXYACCESS = dbscripts

Cmnd_Alias PROXYACCESS = /etc/squid/squid_passwd

but...can that user use sudo to update the squid passwd file from command line?

Quote:

Originally Posted by centosboy (Post 3645592)

but...can that user use sudo to update the squid passwd file from command line?

doesn't appear so:

Code:

[dbscripts@localhost myscripts]$ sudo ./add_remove_squid_users.php



We trust you have received the usual lecture from the local System

Administrator. It usually boils down to these three things:



    #1) Respect the privacy of others.

    #2) Think before you type.

    #3) With great power comes great responsibility.



Password:

dbscripts is not in the sudoers file.  This incident will be reported.

[dbscripts@localhost myscripts]$

You would be better off just putting a single line in sudoers that specified that user for that job only, something like:

dbscripts thishost=(root) /dir/backscript.sh

but post your whole sudoers file so we can advise better.
General format is

usernames/group servername = (usernames command can be run as) command

BTW, you probably need this in regards to your 'Rute for RHEL' comment:
http://www.linuxtopia.org/online_boo...ion/index.html
It covers most stuff and is fairly clear. Just don't try to rush things.

Quote:

Originally Posted by chrism01 (Post 3645820)

The only part I changed near the top about squid passwords

Code:

## Sudoers allows particular users to run various commands as

## the root user, without needing the root password.

##

## Examples are provided at the bottom of the file for collections

## of related commands, which can then be delegated out to particular

## users or groups.

##

## This file must be edited with the 'visudo' command.



## Host Aliases

## Groups of machines. You may prefer to use hostnames (perhap using

## wildcards for entire domains) or IP addresses instead.

# Host_Alias    FILESERVERS = fs1, fs2

# Host_Alias    MAILSERVERS = smtp, smtp2



## User Aliases

## These aren't often necessary, as you can use regular groups

## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname

## rather than USERALIAS

# User_Alias ADMINS = jsmith, mikem



#updating the squid password list

User_Alias PROXYACCESS = dbscripts

Cmnd_Alias PROXYACCESS = /etc/squid/squid_passwd



## Command Aliases

## These are groups of related commands...



## Networking

Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool



## Installation and management of software

Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum



## Services

Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig



## Updating the locate database

Cmnd_Alias LOCATE = /usr/bin/updatedb



## Storage

Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount



## Delegating permissions

Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp



## Processes

Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall



## Drivers

Cmnd_Alias DRIVERS = /sbin/modprobe



# Defaults specification



#

# Disable "ssh hostname sudo <cmd>", because it will show the password in clear.

#        You have to run "ssh -t hostname sudo <cmd>".

#

Defaults    requiretty



Defaults    env_reset

Defaults    env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR \

                        LS_COLORS MAIL PS1 PS2 QTDIR USERNAME \

                        LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \

                        LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC \

                        LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \

                        _XKB_CHARSET XAUTHORITY"



## Next comes the main part: which users can run what software on

## which machines (the sudoers file can be shared between multiple

## systems).

## Syntax:

##

##      user    MACHINE=COMMANDS

##

## The COMMANDS section may have other options added to it.

##

## Allow root to run any commands anywhere

root    ALL=(ALL)      ALL



## Allows members of the 'sys' group to run networking, software,

## service management apps and more.

# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS



## Allows people in group wheel to run all commands

# %wheel        ALL=(ALL)      ALL



## Same thing without a password

# %wheel        ALL=(ALL)      NOPASSWD: ALL



## Allows members of the users group to mount and unmount the

## cdrom as root

# %users  ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom



## Allows members of the users group to shutdown this system

# %users  localhost=/sbin/shutdown -h now

Ok, so you've declared a couple of aliases

Quote:

#updating the squid password list
User_Alias PROXYACCESS = dbscripts
Cmnd_Alias PROXYACCESS = /etc/squid/squid_passwd

but you don't have an entry for that user to actually do anything like eg see my prev post.
Effectively (in programming terms) you've declared 'variables', but not created any 'cmds'.

Quote:

Originally Posted by chrism01 (Post 3647255)

Ok, so you've declared a couple of aliases

but you don't have an entry for that user to actually do anything like eg see my prev post.
Effectively (in programming terms) you've declared 'variables', but not created any 'cmds'.

but all that user does is run a script, which they own, ie have permissions to run and inside the script is a htpasswd command, which has permissions of 755 anyway. The error message in the script always points to the permissions of /etc/squid/squid_passwd

Quote:

Originally Posted by qwertyjjj (Post 3647760)

any ideas?