Tag Info

New answers tagged

1

In addition to /etc/sudoers, sudo will also read files in the /etc/sudoers.d directory. The cloud-init application, commonly used on AWS instances, places a sudoers configuration in that directory for allowing the default user to sudo without a password.


2

RESTRICT The way I interpret "restricting users to the set of programs that do not [allow shell escapes] is often unworkable", it means that it is so common for programs that, on the surface, seem to perform a single, safe task, but actually allow one to run any other program, that one should assume, in the general case, that giving a user access to a ...


0

It fails, because sudo is trying to prompt on root password and there is no pseudo-tty allocated. You've to either log-in as root or set-up the following rules in your /etc/sudoers (or: sudo visudo): # Members of the admin group may gain root privileges. %admin ALL=(ALL) NOPASSWD:ALL Then make sure that your Jenkins user belongs to admin group (or ...


0

From the comments and your further investigations it looks like your devtoolset is modifying the PATH. Unfortunately that includes what appears to be an old or broken sudo command. It would be worth trying to modify the devtoolset include in your .bashrc like this, and then logging back in again: if [ "$(gcc -dumpversion)" != "4.7.2" ]; then scl enable ...


2

By default on enterprise GNU/Linux and it's derivatives, the adduser command creates a user which is disabled until you explicitly specify a password for that user. Here is an example on CentOS 6.5, which should be the same as Scientific Linux. $ sudo adduser test $ sudo grep test /etc/shadow test:!!:123456:0:99999:7::: the reason for this is because ...


1

It's safest to itemize them as jofel suggests. If I wanted to allow someone to use a limited subset of a command's abilities, I would not trust wildcards in a sudoers line to do it. Even if the language was more expressive than shell globs, there are just too many corner cases to keep track of. The "service httpd *" line is relatively safe because (verify ...


2

Just add all needed commands to sudoers separately: %webteam cms051=/usr/bin/systemctl restart httpd.service %webteam cms051=/usr/bin/systemctl stop httpd.service %webteam cms051=/usr/bin/systemctl start httpd.service %webteam cms051=/usr/bin/systemctl status httpd.service


1

Sudo isn't the right tool for this job. It controls what commands you can run, not what files you can access. The right tool for the job is file permissions, with access control lists if the Unix traditional user/group/other permissions aren't enough. Create a group, let's call it webroot, and make it own the directory /var/www/html and the files in there. ...


0

This looks like a permissions issue. Try chmod 644 to make a file readable to all (both you and the web server), or chmod 755 for directories. Perhaps even chmod -R u=rwX,go=rX to give proper access to directories as well: this asks to give the owner read-write permissions, keeping execute permission if it was there, and others (group and anyone) read ...


0

use single quotes since double quotes is doing $ stuff in the first shell


0

I received the same error when trying to :wq a file on a disk that was completely full. If you receive this message, you may wish to check your available disk space.


1

Commenting the line in /etc/sudoers, containing #Defaults requiretty resolved the problem!


0

to run commands that prompt for input and refuse to read from STDIN i run the command in screen, wait a second, then feed input to it.


1

Applications normally read per-user files under the directory indicated by the environment variable HOME. By default, sudo doesn't change the value of HOME, so it still points to the home directory of the original user. Several options can make sudo change it to the home directory of the target user, so make sure that none of them are turned on: Don't set ...


1

tdate has a space in there. So, grep treats the second part of tdate as a filename. You will need to enclose $tdate in double quotes to prevent that. Your command should look like: cat /var/log/secure | grep "$tdate" | grep 'servername su' >> $attempted_su_log


2

You have to quote the argument to grep: grep "$tdate". This is because $tdate expands to two whitespace-separated words, which in turn get passed to grep as two arguments, unless the double quotes are added. Your script could be improved to remove the useless use of cat, and to call grep only once: </var/log/secure grep "$tdate.*servername su" ...


0

I think the best thing that you can do is launch the script with sudo and then launch the processes you want to run as a normal user explicitly with su user or sudo -u user: #!/usr/bin/env bash ## Detect the user who launched the script usr=$(env | grep SUDO_USER | cut -d= -f 2) ## Exit if the script was not launched by root or through sudo if [ -z $usr ] ...


0

Building on my answer to Pre-authorize sudo? (So it can be run later), write two scripts: ABC_script: #!/bin/sh sudo -b ./B_script A && > A_is_done while [ ! -f B_is_done ] do sleep 60 done rm -f B_is_done C B_script: #!/bin/sh while [ ! -f A_is_done ] do sleep 60 done rm -f A_is_done B && > B_is_done Run ...


3

Add your script to the /etc/sudoers file with the NOPASSWD attribute, so that it is permitted to run without prompting for a password. You can tie this down to a specific user (or set of users), or allow it to be run with sudo by anyone on your system. A sample line for a script called /usr/local/bin/bossy might look something like this ALL ALL = (root) ...


-1

Be dumb. use many lines. if A; then if sudo B ; then C fi fi


0

You may want to use the !requiretty option in sudo as well as the NOPASSWD option. But keep in mind this reduces security.


-1

This is due to > being interpreted by the outer shell. The command being run does not know of the redirection, and thus it cannot pass that as an argument to the function. In other words: The > is already executed before sudo is run. What you can do is to have a command called save: save() { sudo tee "$@" >/dev/null } echo something | save ...


1

You probably wanted to pass all as one argument: function pipe { sudo bash -c "$@" } pipe 'echo something > /etc/importantfile'


1

SUDO_USER is documented in man sudo (not sudoers): SUDO_USER Set to the login name of the user who invoked sudo. That is, if you run sudo sh -c 'echo $SUDO_USER' it is a roundabout way of getting the effect of whoami. sudo logs when a user runs (or tries to run) a command through it. You can list them with journalctl /usr/bin/sudo or something ...


2

The only bug I see with your code is that you're running the user's command unnecessarily through sh -c when you should just run it directly. Running it through sh -c buys you nothing but it destroys quoting that the user originally put into the command. For example, try this: sudo /usr/local/sbin/_oob_shim ls -l "a b" should list a file called a b inside ...


1

Some options: sudo -i, that's the most obvious alternative. sudo -l then look for a command that you are allowed to use that you could use to solve the problem, like : editing a file executed by root, like crontab, logrotate, executon yum/rpm... go to the console, and connect as root (only ssh is restricted if I understood) open a graphical session, some ...


1

The question implies SSH (or equivalent) as the only access. The only way generally to get from a user privileged process to a root privileged is via su, sudo, or another site local alternative. If you don't have one then you are hopefully out of luck as the presence of an alternative suggests a security hole of some sort. That said, the suggestion of ...


0

I use notepad++ which has a plugin NppFTP. It can be set up to copy files using sftp, then when you save the file, it uses ftp again to store the file on a remote server.


2

What we do in my team is use puppet to control this sort of file with the config stored in a subversion repository. Each person checks out a copy of the repository to their local machine, uses their favoured editor to make changes and then commits the change. The changes are automatically applied to the live machines by puppet (which runs with admin privs). ...


1

Assuming you're in a group that allows you to sudo, then: sudo -i will give you root access and allow you to repair /bin/su. Remember that you use your user's password with sudo - not root's password.


-4

scp su command to your home dir, and run it, of course, careful it compiled for centos and for your arch. aftre comming root , cp su to /bin/


0

It is better to find what you need to include in your chroot than to find out you forgot some program that could be used as a back-door. You just make links to the material you need from under the chrooted structure. And anything you overlooked to include you find out about on the first compile run. Whenever I had this requirement I have used virtual ...



Top 50 recent answers are included