So as you said yourself @krzysto, the solution is to add the following to the sudoers file
beans ALL = (root,apache) NOPASSWD: /usr/bin/ksh -c /opt/renovations/var/script-*.sh
beans ALL = (root,apache) NOPASSWD: /usr/bin/bash -c /opt/renovations/var/script-*.sh
The next piece that is missing is to make sure that the group has execute permissions on the scripts, so that you can execute them.
The major difference between sudo
and su
is the mechanism used to authenticate. With su
the user must know the root
password (which should be a closely guarded secret), while with sudo
the user uses his/her own password. In order to stop all users causing mayhem, the priviliges discharged by the sudo
command can, fortunately, be configured using the /etc/sudoers
file.
Both commands run a command as another user, quite often root
.
sudo su -
works in the example you gave because the user (or a group where the user is a member) is configured in the /etc/sudoers
file. That is, they are allowed to use sudo
. Armed with this, they use the sudo
to temporarily gain root
privileges (which is default when no username is provided) and as root
start another shell (su -
). They now have root
access without knowing root
's password.
Conversely, if you don't allow the user to use sudo
then they won't be able to sudo su -
.
Distros generally have a group (often called wheel
) whose members are allowed to use sudo
to run all commands. Removing them from this group will mean that they cannot use sudo
at all by default.
The line in /etc/sudoers
that does this is:
## Allows people in group wheel to run all commands
%wheel ALL=(ALL) ALL
While removing users from this group would make your system more secure, it would also result in you (or other system adminstrators) being required to carry out more administrative tasks on the system on behalf of your users.
A more sensible compromise would configure sudo
to give you more fine grained control of who is allowed to use sudo
and who isn't, along with which commands they are allowed to use (instead of the default of all commands). For example,
## Allows members of the users group to mount and unmount the
## cdrom as root
%users ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom
(only useful with the previous %wheel line commented out, or no users in the wheel
group).
Presumably, distros don't come with this finer grained configuration as standard as it's impossible to forecast what the admin's requirements are for his/her users and system.
Bottom line is - learn the details of sudo
and you can stop sudo su -
while allowing other commands that don't give the user root
shell access or access to commands that can change other users' files. You should give serious consideration to who you allow to use sudo
and to what level.
WARNING: Always use the visudo
command to edit the sudoers
file as it checks your edits for you and tries to save you from the embarrassing situation where a misconfigured file (due to a syntax error) stops you from using sudo
to edit any errors. This is especially true on Debian/Ubuntu and variants where the root
account is disabled by default.
Best Answer
EDIT: There is a way to do this quickly and easily with no additional setup.
This will transfer all the file's content exactly. If you care about having the file permissions and/or timestamps match the original, you will need to fix those separately using
chmod
andtouch
.ORIGINAL ANSWER:
The problem here is that:
secondUser
doesn't have access to your home directory.secondUser
's home directory.As such, regardless of whether you run the
cp
command as yourself or assecondUser
, it can't perform the file copy.Given that you said you don't have
root
access, the obvious answer is to copy the file through an intermediate world-readable location such as/tmp
and change the permissions of the file to world-readable. If the data in the file is sensitive you may not want to do this, however, because anyone on the server will be able to read the file while it is in transit. If it's not sensitive data, just do:A better option, if you can arrange it, is to make a group that contains only you and
secondUser
, andchgrp
the copy of the file in/tmp
to be owned by that group. This way you don't need to make the file world-readable, but only readable by the group (withchmod g+r /tmp/file
). However,groupadd
itself requires root access, so this is unlikely to be easy to arrange. Depending on the circumstances (if you are frequently trying to share/collaborate withsecondUser
it might be applicable), you could consider asking your administrator to set up this group for future use.