I've added superuser sroot with the following command.
useradd -o -r -c "service root" -g 0 -u 0 -m -d /root -s /bin/bash sroot
When I try to switch to that user I get the following:
[admin#machine ~]$ su - sroot
Password:
TERM=[xterm-r6]?
basename: missing operand
Try `basename --help' for more information.
whoami shows that I'm root now but commands that requires root access still cannot be executed.
When I login under usual root everything works fine.
[admin#machine ~]$ uname -a
Linux <myhostname> 2.6.18-194.el5PAE #1 SMP Fri Apr 2 15:37:44 EDT 2010 i686 i686 i386 GNU/Linux
Thanks in advance!
Well, I tested with non-standard linux commands, but with scripts added with installed rpm. Those commands check $LOGNAME variable and require to be root only, not sroot.
Thanks #thatotherguy for your comment, which directed me to the right path to search.
Related
I'm trying to execute multiple commands on a remote server. The issue I'm having is that after the sudo command is ran, the ssh connection gets closed automatically.
The main test that is failing:
ssh -i "/path/to/key/id_rsa" user#server << EOF
sudo ls -la "/etc/redhat-release"
cat "/etc/redhat-release"
EOF
Returns only the ls result
-rw-r--r-- 1 root root 55 Jan 29 2013 /etc/redhat-release
While if I put both commands on the same line, i.e.
ssh -i "/path/to/key/id_rsa" user#server << EOF
sudo ls -la "/etc/redhat-release"; cat "/etc/redhat-release"
EOF
I will get the result of both commands
-rw-r--r-- 1 root root 55 Jan 29 2013 /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 (Santiago)
Now for the weirdest part:
the main test does work on an other server with identical configuration. There are sets of servers where it works, and other sets where it doesn't.
if I remove the sudo from the test, I will get the result from both commands, so it's not an ssh limitation
e.g.
ssh -i "/path/to/key/id_rsa" user#server << EOF
ls -la "/etc/redhat-release"
cat "/etc/redhat-release"
EOF
-rw-r--r-- 1 root root 55 Jan 29 2013 /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 (Santiago)
Additional information:
Both commands have the NOPASSWD flag in the sudoers file so no password is asked.
requiretty is commented out.
ssh version: OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
SELinux is disabled
the ssh -vvv option doesn't show any significant difference in the logs between a working and non-working server
sshd_config are the same between a working and non-working server
I'm assuming here that there must be some configuration difference between the sets of servers because they are consistent with each-other, but I can't figure out what.
One possible workaround:
ssh -i "/path/to/key/id_rsa" user#server sudo bash << EOF
ls -la "/etc/redhat-release"
cat "/etc/redhat-release"
EOF
Check your sudo version (sudo -V).
Turns out one server was running Sudo version 1.8.6p3 while the other was on Sudo version 1.8.21p2 and a was running in a bug which was fixed in sudo 1.8.20:
Fixed an issue where sudo would consume stdin if it was not connected to a tty even if log_input is not enabled in sudoers. Bug #786.
Updating the sudo version fixed the issue.
I can't understand how exactly this works in Linux.
For example, I want only users in some group have access to execute some file (I hope this is possible without visudo).
I create a system user and system group like:
useradd -K UID_MIN=100 -K UID_MAX=499 -K GID_MIN=100 -K GID_MAX=499 -p \* -s /sbin/nologin -c "testusr daemon,,," -d "/var/testusr" testusr
I add my current user user to the group testusr (may be not cross platform):
adduser user testusr
I create some test shell file and set permissions:
touch test.sh
chmod ug+x test.sh
sudo chown testusr:testusr test.sh
But I still can't start test.sh as user:
./test.sh
-> Error
Now I look for some system groups like cdrom to check how they work. My user is in cdrom group and can use the cd rom on my computer:
$ ls -al /dev/cdrom
lrwxrwxrwx 1 root root 3 апр. 17 12:55 /dev/cdrom -> sr0
$ ls -al /dev/sr0
brw-rw----+ 1 root cdrom 11, 0 апр. 17 12:55 /dev/sr0
Addition:
./test.sh command starts to work as I want after system reboot. Strange...
I'm on Ubuntu Studio 15.10
The group changes are reflected only upon re-login.
I installed ffmpeg on centos as root user. How can update permission so that apache (httpd) can run the ffmpeg command?
-rwxr-xr-x. 1 root root 24M Mar 4 03:43 /root/bin/ffmpeg
I tried to link to /usr/bin
cd /usr/bin
ls -s /root/bin/ffmpeg
But when still not works. I guess because apache not have shell avaiable?
su apache -c whoami
This account is currently not available
As #pbu comment states, if you follow this installation guide http://trac.ffmpeg.org/wiki/CompilationGuide/Generic but replacing '$HOME' with '/usr/local', the apache (httpd) user will be able to execute it.
I have a script which calls some other bash, python, and ruby scripts. The script is similar to the following:
#!/bin/bash
set -x
./aux1.py
./aux2.sh
When I run the script from the command line, it runs but it gives me the following output:
./script.sh: line 5: ./aux1.py: Permission denied
The aux.py script has #!/usr/bin/env python at the top; when I call it from the command line with ./aux.py it is fine, however when called from this script in the exact same way I get this error. The strange part is that this only happens when I run the script with ./script.sh; when I run the script with bash script.sh the auxilliary scripts work perfectly.
I'm using Linux, why does this happen?
Update, 3 March 2014
There's nothing conflicting in the PATH, and all of the scripts are chmod +rx. uname -srvmo gives
Linux 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Dec 13 06:58:20 EST 2013 x86_64 GNU/Linux
and there's no more information available in uname -a. SELinux is enabled, but I'm not an administrator so I can't access that information.
Before launching the main script you must be sure that all the subscripts have got the right permissions. In particular you are interested in the permission for you (your user and owner of the files) to execute the file. This is a short tutorial on permissions.
http://blog.pluralsight.com/linux-file-permissions
http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions
If this is the problem (and it look so), the simpler solution is to run the following commands
chmod u+x script.sh aux1.py aux2.sh
To check whether you have permission to execute simply run
ls -l
You should see something like
-rwxr--r-- 1 youruser youruser 26 Feb 28 21:44 script.sh
-rwxr--r-- 1 youruser youruser 32 Feb 28 21:44 aux1.py
where you should see a "x" in the 4th column corresponding to the file.
Maybe type sudo su before running your script so that you are the root user. When the script completes simply type exit to get out of root. Type exit again to close the shell.
:D
I have a .sh file (lets say adduser.sh) that is executed via a cronjob that contains the commands to create an FTP user.
The adduser.sh file looks like so...
#!/bin/bash
mkdir /var/www/vhosts/domain/path;
useradd -d /var/www/vhosts/domain/path -ou <uid> -g <group> -s /bin/false <username>;
echo <password> | passwd <username> --stdin;
Now here is my problem. If I run it directly through SSH using...
sh adduser.sh
...no problems and it works as intended.
But if I let the cronjob run it the directory is created but the user is not added.
What gives?
As it stands, there is an alternative to useradd known as adduser. In Debian or Ubuntu, adduser is a perl script and performs sequential functions like create the user using adduser, assign it to a group, create home directory etc.
As per adduser man page-
adduser and addgroup are friendlier front ends to the low level tools
like useradd, groupadd and usermod programs, by default choosing
Debian policy conformant UID and GID values, creating a home directory
with skeletal configuration, running a custom script, and other
features.
In Fedora, RedHat, and CentOS, adduser is just a symbolic link to useradd.
[root#hobbit ~]# which /usr/sbin/adduser
lrwxrwxrwx 1 root root 7 2012-09-20 20:20 /usr/sbin/adduser -> useradd
If you are on any on the above OS then you can try adduser redirect 2> to a add_user.log file and check the file to see if something goes wrong.
I have resolved this simply adding /usr/bin/ to the useradd function.
#!/bin/bash
mkdir /var/www/vhosts/domain/path;
/usr/bin/useradd -d /var/www/vhosts/domain/path -ou <uid> -g <group> -s /bin/false <username>;
echo <password> | passwd <username> --stdin;
Thanks everyone for helping me get on the right track. Hope this helps someone out there.