Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
I'm trying to integrate git, gitweb, gitolite, apache.
For the moment I get each time a "Server Error". Apache logs:
[cgi:error] [...] AH01215: (13)Permission denied: exec of '/usr/sbin/suexec2' failed, referer: http://git/
/usr/sbin/suexec2 -V gives me:
-D AP_HTTPD_USER="wwwrun"
meaning that apache will run as user "wwwrun". The user wwwrun belongs to the group git:
git:x:1000:git,sav,tame,wwwrun
and these are the permissions of /usr/sbin/suexec2
-rwsr-x--- 1 root git 18936 Oct 24 14:19 /usr/sbin/suexec2
I have restarted Apache several times, applied newgrp... I'm out of ideas.
SOLVED but with no apparent reason.
I applied these commands several times:
newgrp
/etc/init.d/apache2 restart
log out
and for one our another reason it did not work, and now it does... I didn't change a thing... these are the last commands I did:
git:~ # sudo -u wwwrun /usr/sbin/suexec2 -V
sudo: unable to execute /usr/sbin/suexec2: Permission denied
git:~ # vim /etc/group
git:~ # vim /var/log/messages
git:~ # vim /var/log/apache2/error_log
git:~ # ls -l /usr/sbin/suexec2
-rwsr-x--- 1 root git 18936 Oct 24 14:19 /usr/sbin/suexec2
git:~ # vim /etc/group
git:~ # cat /etc/group | grep wwwrun
git:x:1000:git,sav,tame,wwwrun
git:~ # ^C
git:~ # /etc/init.d/apache2 restart
redirecting to systemctl restart apache2
git:~ # vim /var/log/apache2/error_log
git:~ # sudo -u wwwrun /usr/sbin/suexec2 -V
the only command that might have changed something is the apache restart, but I had done that already for many times...
Related
i want to ask for a specific user to use certain root commands in redhat?
my server run redhat OS 7.6. i dont have any idea how to set a user that can run certain commands from root.
let say i have one user id name MY_CIT, so MY_CIT can run certain commands for example to create print queue #lpadmin -p printer -v socket://printer:9100 -E
so MY_CIT no need root access to trigger the command.
Anyone experience on this? kindly help. thanks
You'll be able to use file ACLs. As a test I removed execute permissions from the nano command, just to show how this will work.
You won't need to do this, however, you will need root permissions to the machine. Instead of nano, use 'lpadmin' as per your requirements
[root#server bin]# chmod o-x /bin/nano
[root#server bin]# ls -lah /bin/nano
-rwxr-xr-- 1 root root 202K Jun 10 2014 nano
To test, we change to user1 and try use nano to edit a file:
[user1#server ~]$ nano file1
-bash: /bin/nano: Permission denied
Now, as root again, we add an ACL to the nano program. This allows only user1 to execute the program.
[root#server bin]# setfacl -m u:user1:x /bin/nano
Display ACL with getfacl:
[root#server bin]# getfacl /bin/nano
getfacl: Removing leading '/' from absolute path names
# file: bin/nano
# owner: root
# group: root
user::rwx
user:user1:--x <<-- Note this
group::r-x
mask::r-x
other::r--
As user1, we are able to use the nano program, but not as user2:
[user1#server ~]$ nano file1
[user1#server ~]$ ls
file1
[user1#server ~]$ exit
logout
[root#server bin]# su - user2
[user2#server ~]$ nano file1
-bash: /bin/nano: Permission denied
ACLs allow admins to extend permissions past just user/group/other. You're able to set permissions for specific users on the system.
Run command with a root privilege:
sudo visudo
It opens file /etc/sudoers for edit.
Add this line at the end of the file (and after keep one blank line):
MY_CIT ALL = NOPASSWD: /usr/sbin/lpadmin
where:
MY_CIT - name of your user
/usr/sbin/lpadmin - path to executible file. Note please that in your distro path can be different. You can check this with command whereis lpadmin.
After user can run command lpadmin with arguments with sudo without password:
sudo lpadmin ...
I am getting the following error while switching to root user
[~]# sudo su -
sudo: must be setuid root
The current permission of sudo is
[~]# ls -l /usr/bin/sudo
---s--x--x 2 root root 190904 Mar 10 2014 /usr/bin/sudo*
It's may CLOUDLINUX 5.11 x86_64 cPanel live server. Any suggestions on how to fix this?
Try to Enter system with recovery mode.(maybe Esc or Shift when start.)
Then choose the content row with 'root' in recovery menu.
Then:
#mount -o remount,rw /
#chown root:root /usr/bin/sudo
#chmod 4755 /usr/bin/sudo
now, restart...
try:
sudo ls
but if following exception raise:
#sudo: /usr/lib/sudo/sudoers.so must be owned by uid 0
#sudo: fatal error, unable to load plugins
Then you need entering recovery mode again and try:
#chown root /usr/lib/sudo/sudoers.so
restart...
I have fixed it my self. Currently the user is set to jailed shell and now I changed it to normal shell and could switch to root. – Techiescorner
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I'm using Docker 1.6 on a CentOS 7 host, using CentOS 7 containers.
In most of my containers, DNS doesn't work, because /etc/resolv.conf cannot be read, even by root:
[root#7ba55011e7ab etc]# ls -l /etc/resolv.conf
ls: cannot access /etc/resolv.conf: Permission denied
This happens in most of my containers, even containers that are created directly from the standard Docker centos:latest image. (This problem also occurred when I was using the standard Docker debian image.) The only container in which resolv.conf is readable is the very first one I created from the stock centos image.
Needless to say, I've bounced Docker multiple times, as well as rebooted the host machine. I've also tried using --dns hostname in the OPTIONS in /etc/sysconfig/docker. But of course that doesn't help because it's not the contents of resolv.conf that are a problem, but rather the fact that I can't read it (even as root).
I understand that /etc/resolv.conf is "bind mounted" from the host's /etc/resolv.conf. The host's copy of this file looks fine, and the permissions look reasonable:
[root#co7mars2 etc]# ls -l /etc/resolv.conf
-rw-r--r--. 1 root root 106 Apr 30 18:08 /etc/resolv.conf
I am not able to umount /etc/resolv.conf from within the container:
umount -f -r /etc/resolv.conf
umount: /etc/resolv.conf: must be superuser to umount
Is there a fix for this?
I see some related issues on the Docker github site, such as https://github.com/docker/docker/issues/2267, but they address enhancements for complex use cases, rather than my situation, where I'm just dead in the water.
By the way, I've tried this on two separate and unrelated CentOS 7 hosts, with the same results.
Thanks.
To add to Daniel t's comment, issue 11396 mentions that you can give the container write access (meaning at least read access too) in any one of the following ways:
Disable SELinux for the entire host: setenforce 0
See issue 7952:
# Example of proper behavior on fresh btrfs system when SELinux is in Permissive mode
[~]$ getenforce
Enforcing
[~]$ sudo setenforce 0
[~]$ getenforce
Permissive
[~]$ sudo docker run fedora echo "hello world"
hello world
[~]$ sudo setenforce 1
[~]$ sudo docker run fedora echo "hello world"
echo: error while loading shared libraries: libc.so.6: cannot open shared object file: Permission denied
Set the directory SELinux policy to allow any container access:
chcon -Rt svirt_sandbox_file_t /var/db
Make the container --privileged.
This disables not only SELinux constraints but also the default cgroups restrictions:
docker run --privileged -v /var/db:/data1 -i -t fedora
Disable SELinux policy constraints for this container only:
docker run --security-opt label:disable -v /var/db:/data1 -i -t fedora
Run the container processes as SELinux process type unconfined_t:
docker run --security-opt label:type:unconfined_t -v /var/db:/data1 -i -t fedora
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last year.
Improve this question
I have been trying to enable logging in my OpenLDAP setup (in Oracle Enterprise Linux 6.5) , but no logs are being generated in /var/log/slapd/slapd.log.
Followed these steps to enable logging :
Edited the slapd.conf file :
# grep -i loglevel /etc/openldap/slapd.conf
loglevel -1
Did the setup for the log directory in /var/log/slapd
# cd /var/log/slapd ; ls -ltr
-rw------- 1 root root 217 May 21 19:48 slapd.log
Edited the rsyslog config file
# grep -i local4 /etc/rsyslog.conf
local4. /var/log/slapd/slapd.log*
restarted the openldap service and also the rsyslogger :
# service rsyslog restart
# service slapd restart
But even after doing these steps , we are not seeing logs captured in the slapd.log file . Only log seen is the below line :
more /var/log/slapd/slapd.log
May 21 19:48:12 sprdneval slapd[2961]: #(#) $OpenLDAP: slapd 2.4.39 (Aug 16 2014 20:41:55) $#012#011mockbuild#ca-buildj3.us
.oracle.com:/builddir/build/BUILD/openldap-2.4.39/openldap-2.4.39/build-servers/servers/slapd
Am i missing to do something blindingly obvious ?
Regards,
Hari
If you are using the OnLine Configuration (OLC) have a look at Zytrax. It explains quite well how to use and configure it.
Same problem here ('loglevel any' and 'logfile /var/log/slapd/slapd.log' options in slapd.conf and in the cn=config, but no debug output in the logfile).
I've just solved the problem by adding "-d any" to the command line arguments of the slapd
/usr/bin/slapd -d any -u ldap -g ldap -h "ldap://127.0.0.1/ ldaps:/// ldapi:///"
I see the same issue and posted my question at Serverfault about what '-s' option means.
If you see olcLogLevel setting at current config:
$ sudo grep olcLogLevel /etc/openldap/slapd.d/cn=config.ldif
olcLogLevel: 0
Then, you can change it by:
$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// <<EOF
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: 256
EOF
If you don't see olcLogLevel setting, then you need to newly create the entry. I haven't seen the case but I think it will be done by change 'changetype' above from 'modify' to 'add'.
My environment is CentOS7.9 so that the path would be different from yours.
You can do and check df -h to check disk space and delete heavy files which you do not require (like messages*.gz) from /var/log/ also empty the content of /var/log/slapd/slapd.log
Now you reboot your system and check service slapd status.
Hope ,it works now.
this command works
ssh -t www.foo.com 'sudo ls -l'
I immediately get asked for my password, once entered I get the directory contents
if I try to pipe this command it fails - I never get asked my password so I never get any contents.
ssh -t www.foo.com 'sudo ls -l' | grep 'foo'
This is a basic example, I know I could pipe/grep the output in my "ls" command. for my application I need to pipe the output through a program on my host.
In order to not be asked for a password to issue sudo commands, you need to have an entry in /etc/sudoers (or better, a file in /etc/sudoers.d) that lets you do it. There is a nice question on using sudoers here.
A sudoers config to allow you to run ls as root could be:
<yourusername> ALL = (root) NOPASSWD: /bin/ls
One thing to look out for is that ls is quite likely to be a shell built-in, so you may have trouble allowing it. You should be able to set your shell to defer to the system binary instead.
Trying to push your real password through it is not a secure solution.
ssh -t www.foo.com 'echo your_pass | sudo -S ls -l' | grep 'foo'
Also possible:
ssh -t www.foo.com 'sudo -S ls -l <~/passwd.txt' | grep 'foo'
The reason you are not getting prompt for password is because you are feeding the output of "ssh -t www.foo.com 'sudo ls -l'" to the pipe where you are grepping for 'foo'. So in this case the password prompt won't be shown, but actually the process is waiting for your input.
Try giving the password on the blank new line you get after running the command.
I tried this and it worked. Just for example,
$ ssh -t user#host 'sudo ls -l /' | grep 'root'
user#host's password: <===== After this, it waits for user input to feed the password for sudo user.
Connection to host closed.
drwxr-xr-x 2 root root 4096 2011-08-31 15:33 bin
dr-xr-xr-x 24 root root 4096 2014-07-14 00:52 bldmnt
dr-xr-xr-x 2 root root 4096 2011-03-23 15:51 blr
drwxr-xr-x 3 root root 4096 2011-08-31 15:36 boot
.
.
.
Try it and see if it works for you.