Tag Info

New answers tagged

0

You could also take a look at privacyIDEA, which does not only provide you the possibility to use OTP for login to the machine (or for doing su/sudo) but it can also do OTP offline. Furthermore it is capable of managing your SSH keys. I.e. if you have many machines and several root users, all SSH keys are stored centrally. Thus it is easy to "revoke"/delete ...


0

You must set the SSH based on keys in your situation. Whatever it's called from, the SSH tool itself just reads the config AND keys, AND if the remote server accepts key-only auth, you won't have a password prompt. Just make a key on a remote host under the user you wish to execute your command, enable key-based auth, on your local host AND make "su" to the ...


0

If you use bash you can do here-doc $ su - user -s/bin/bash -c <<EOF export X=1 echo $X EOF That way you can execute many commands and keep the state inside a script. The same with sudo sudo -u user <<EOF your script here EOF


5

Allowing a less trusted user to run apt-get update is ok. They worst they can do is consume a lot of bandwidth and fill up some disk space, and they have plenty of other means to do this unless you've taken stringent measures to prevent this. Allowing a user to run apt-get upgrade is likely to give them root access. Some packages query the user and might ...


-1

This line in the sudoers file works for me to allow a user to run useradd someuser ALL=/usr/sbin/useradd * -m The * is a wildcard, there are other wildcard symbols, read man sudoers


1

Just add the options to the command: admin ALL = NOPASSWD: /usr/bin/netstat -i admin ALL = NOPASSWD: /usr/bin/netstat -r Then admin will be able to run sudo netstat -i, but not sudo netstat etc.


1

Edit the sudores file with visudo and add one line (or as many as you need) like in my example admin ALL=/bin/netstat -r admin ALL=/bin/netstat -i ALL= can be a hostname, IP or localhost The sudoers file is very well commented, at least in my CentOS


0

Create a script #!/bin/sh netstat -i call it supernetstat.sh (don't forget permission 755,better 700) then you can create an alias command on sudo and give permission to user


4

The built-in delay is to slow down the process of password guessing. Looks like someone could programmatically guess about 27 potential passwords per minute, which, as you've observed is a good deal less than if there was no delay.


0

Try using the -E parameter on sudo: -E, --preserve-env Indicates to the security policy that the user wishes to pre‐ serve their existing environment variables. The security policy may return an error if the user does not have permis‐ sion to preserve the environment.


1

Assuming that you want to be editing root's crontab, sudo must give you root authority. After it does so, crontab will invoke ${VISUAL:-${EDITOR:-vi}} (it'll use $VISUAL unless it doesn't exist; in that case it'll use $EDITOR unless it doesn't exist; in that case it'll use vi). You have a few possible solutions. They all subvert the security provided by ...


1

If the instance doesn't contain anything important, I'd suggest chalking this up as a learning experience and blowing it away and starting over. If you must fix it, you could shut down the instance, saving the disk image, and mount it on another instance and fix the permissions.


1

Yeah - that is a "gotcha" for sure. Use visudo in the future to avoid that problem. I have a CentOS 7 VM, which is essentially the same as RHEL7; and I was able to use su - to become root without using sudo, because I know the root password. Do you know your password for the user, root?


0

Check set -o to see if maybe posix mode is enabled. If so, disable with set +o posix PS: This answer is more suited for someone who stumbles upon the question via a search engine... not for your particular setup.


1

If you follow the next link on the documentation page: http://www.centos.org/docs/5/html/5.2/Deployment_Guide/s2-pam-timestamp-remove.html you can find a reference to the pam_timestamp_check utility. The pam_timestamp_check utility will check the validity of the file and the return value can be checked. See also man pam_timestamp_check for details. On my ...


0

With a caveat, the "right way" to allow a program to have root privileges and be run by any user, is to use setuid and setgid flags passed to chmod. This tutorial explain the process. You must be root to apply the setuid or setgid flags, and the program must be owned by root. The caveat is that it is extremely insecure to allow a user to run a program with ...


5

Pro tip: There is never really a good reason to run sudo su. To run a command as a different user, use sudo -u username command. If you want a root shell, run sudo -i or sudo -l. If you have activated the root account, you can also run su alone, but sudo su is just not useful. And yes, I know you see it everywhere. That said, sudo has the -E switch which ...


3

You can do it without calling login shell: sudo DUMMY=dummy su ec2-user -c 'echo "$DUMMY"' or: sudo DUMMY=dummy su -p - ec2-user -c 'echo "$DUMMY"' -p option make sudo preserve environment variables.


2

In the realm of solving the problem rather than answering the question, here's the most obvious (to me) way to source a file which only root can read: source <(sudo cat /etc/environment) This uses process substitution. It takes the output of the cat command and turns it into a pseudo-file, which you can pass to source. source then runs the commands ...


1

The variable expansion is performed by your interactive shell. You're running the command sudo with the arguments echo and tim. If you want the expansion to happen in the shell invoked by sudo, tell it to run a shell and pass the string echo $ME to that shell: sudo sh -c 'echo $ME' sudo removes most variables from the environment, because they can be a ...


-1

sudo just executes a command as another user. As a result current environment is used. However su changes user ID or become superuser. If you haven't set a password to root user, you run sudo su in order to become superuser. And when you become superuser, naturally environment is changed.


4

The environment variable expansion is done by the shell so the command you're actually running is "sudo echo tim". This is all done before sudo is run.


2

sudo expects a command but you are giving a shell builtin so it cannot find the command. If you write type source, you can see the output: source is a shell builtin and the output of which source is empty. For example sudo strace will work and which strace will give output because strace is a command. Edit: Also, you can see sudo su;sudo source ...


8

source is a shell builtin, so it cannot be executed without the shell. However, by default, sudo do not run shell. From sudo Process model When sudo runs a command, it calls fork(2), sets up the execution environment as described above, and calls the execve system call in the child process If you want to explicitly execute shell, use -s option: # ...


1

Wildcards with sudo commands are a bit dicey. They can appear to give you security without actually doing so. To sudo, the * does not mean "any files under this directory" as it does in the shell. Rather, it means "any additional options" and must stand alone. Unfortunatley, you cannot in sudo restrict part of the arguments, and further, it wouldn't be ...


4

From the sudoers(5) man page: The sudoers policy plugin determines a user's sudo privileges. For the targetpw: sudo will prompt for the password of the user specified by the -u option (defaults to root) instead of the password of the invoking user when running a command or editing a file. sudo(8) allows you to execute commands as someone else ...


1

Depending on what files you want, you can create a new group (/etc/group) and make the file writable (and the directory containing it if you want the user to create new files) by that group (e.g., chgrp <groupname> <file>; chmod g+w <file>


2

There is an incredible amount of files that one can modify to "install a backdoor" on the system (editing /etc/group is the easiest, but there are lots of more stealthy way to achieve it). It is also possible to disable this noexec protection by editing /etc/sudoers file! I wouldn't rely on NOEXEC to make "sudo $editor" secure. it is not secure. DO use ...


0

sudo doesn't give you an login shell unless you ask for it with -i. So you'll find that without it you'll need to load the system's completions: . /etc/bash_completion If you run with -i, then $HOME will be ~root, and so anything written to the user's ~/.bashrc won't get read. If you can separate out the completion stuff from the rest of your ~/.bashrc, ...


0

In short, Sudo allows privilege escalation, while a user's groups allow access to things owned by the group.


1

For each of the urls mentioned in the error message in the question, do a search for it. Then remove it from the relevant file in /etc/apt/sources.list.. For example cd /etc/apt/sources.list.d grep -R http://old-releases.ubuntu.com/ubuntu/dists/trusty/main/binary-amd64/Packages This will give you a name of a file in /etc/apt/sources.list.d. Then go into ...


0

It appears that my Mint 17.1 is not using /etc/apt/sources.list, but rather /etc/apt/sources.list.d/official-package-repositories.list Please try the following command: # inxi -r Let me know what you get.


0

chmod u+s /usr/bin/growisofs solves this problem. But it's a good example of the "wrong way to do this" since it breaks the security afforded through sudo. SetUID growisofs presents an even worse security problem than carefully configuring sudo and it's all of no value for a personal desktop system, IMO.


0

The problem isn't 'what could happen' as much as what couldn't happen. I mean, vi is quite a powerful tool, and using it as a privileged user gives many potential avenues of attack and exploit. And that's why you shouldn't do it - because you're playing 'block the mousehole' in a big old house. Anything interactive is 'risky'. Avenues of attack: Shell ...



Top 50 recent answers are included