Tag Info

New answers tagged

0

In may case, it is found the hostname (that was configured in /etc/sysconfig/network) doesn't exist in /etc/host file; so upon adding in afore-mentioned file, the file opens promptly


0

What about using setuid so that the process can be run as root? chmod 4555 tool.php chown root tool.php I think that should do it correctly.


4

While this approach lends itself to generating bad feelings, if this is a necessary evil, I'd begin by making sure that the server is segmented from the network -- either accessible only by a few hosts in a LAN or listening only to hosts that have authenticated against a VPN (or SSH tunnel). In short, try not to let this host be low-hanging fruit. It is ...


1

One approach is to separate the web interface from the execution layer, i.e. use the web interface as the UI and to schedule actions. Then run a second job with root privileges that polls the queue, validates and executes scheduled tasks and which reports exit status back. A slight modification to that is where instead of having the poller run independently ...


1

Yes indeed - from a control and logging perspective sudo is much better. For example - if you su the only event captured in the logs is you su'ing. Anything after that goes as root. And if you've ever looked at logs in Unix/Linux you know root does a butt load of stuff. Sudo on the other hand logs pretty much everything AS the originating user.


0

I've solved it. The problem was not about NFS. sudo kept asking me for passwords because I had wrong time on the diskless server. I set the time to the correct value and sudo worked. locate did not update db because there were PRUNEFS="nfs NFS nfs4 ..." in the /etc/cron.daily/locate file. I removed nfs from PRUNEFS and it worked.


2

I am using a wrapper function around screen for the user(s) that I sudo su to. This is the wrapper function that I've added to the user(s) ~/.bashrc: function screen() { /usr/bin/script -q -c "/usr/bin/screen ${*}" /dev/null } This allows me to use all of the options and parameters for screen that I might want to use. I am contemplating on putting this ...


4

Let's look your cases: su - will run a /bin/sh as the root user using the root environment. The root password is needed and logging MAY be logged depending on syslog settings (usually is by default to /var/log/auth.log). sudo /bin/sh will run shell as the root user using the current set of environment variables (with some exceptions as would be ...


0

*Given the above concerns, is it ever a good idea to allow users to use sudo su * No, not in my opinion. It has no practical advantage over allowing them to su except they don't need the root password to do it. or su - at all? Since I always disable root logon, su is necessary and on balance, makes the server more secure.


9

This will replace any instance of the string "sudo" (sans quotes) with "sudo -n" (sans quotes): curl https://install.meteor.com | sed 's/sudo/sudo -n/g' | /bin/sh From the sudo manpage: -n' The -n (non-interactive) option prevents sudo from prompting the user for a password. If a password is required for the command to run, sudo will display an ...


0

Why not modify the script before using it : curl https://install.meteor.com > /tmp/script, modify it in /tmp/script, then run it /bin/sh /tmp/script Edit: Or if the password is asked, just type three times a bad password and you will be rejected


3

You are trying to install the httpd package, containing version 2.2 of Apache, but you already have httpd24, containing version 2.4 of Apache, installed. Before doing anything else, first decide which version you actually want.


6

Actually, the command string listed in the sudoers is requiring to be the exact match. In your example, you put the command string /usr/bin/yum update in the sudoers configuration line, but the command you finally executes is yum -y update. (the difference is the extra parameter -y). Then, the mismatch in command string caused the sudoers failed to hit ...


1

Check if you have the following in your sudoers file : %sudo ALL=(ALL:ALL) ALL If yes, try to comment it : #%sudo ALL=(ALL:ALL) ALL


1

Try: Cmnd_Alias YUM = /usr/bin/yum user ALL=(ALL) NOPASSWD: YUM


2

The way to handle this is to collect all the information about what access the program needs, and then explicitly allow only that access in a custom policy module. This is fairly easy to do. First, you set the domain permissive, so that SELinux temporarily does not enforce its rules. It will still log the denials, and later you will use these logs. ...


2

Of course you can that. Is it safe? First be sure to set password on user ubuntu. Edit the sudoers file with command visudo otherwise be very careful. Find the line matching ubuntu user and change it to ubuntu ALL=(ALL:ALL) ALL username is in the beggining of the line first ALL indicates to which hosts it applies (in that case all of them) second ALL is ...


1

Yes, but make sure to set that user's password to something known before you do that.



Top 50 recent answers are included