New answers tagged

0

Many admins doesn't want to in sudoers enumerate what different groups of users should be able to do so... they add every admin to the sudo group and enables the default '%sudo ALL=ALL...' item in sudoers. Think if you have a group of admins which is responsible for the postgres cluster in a part of the system: add those users to a group in the system which ...


2

Both docker and sudo can give full root access. The worst case risk of both is basically the same. If a hacker gets full root access then recovery usually involves rebuilding your server. They can do anything and hide anything on your server. So sudo is a lesser risk mostly because the root access can be limited by configuration. Sudo has configurable ...


1

Unix permissions are set up so that a normally privileged user can do minimal permanent damage to the system. The sudo command elevates a trusted user's permission to root, which can do anything to the system, including make changes to the operating system that will cause it to malfunction. This makes sudo, and root access in general, dangerous. Naive users ...


8

Executing a program in a different target group is the whole point of the -g option. And there's no restriction on combining -u with -g. The sudoers policy permits any of the target user's groups to be specified via the -g option as long as the -P option is not in use. It's not explained clearly, but what this sentence is referring to is what sudo lets you ...


2

You can experiment with this by copying the id program somewhere, and changing its permissions. This will show that exampleprog runs with an effective uid of root, and a real uid corresponding to user1. Consider what would happen if you logged in as user1 and ran exampleprog: since the latter is suid root, you’d expect it to run with an effective uid of root....


0

Try adding no_access_check to /etc/pam.d/system-auth (which should be a link to /etc/pam.d/system-auth-ac) after the first occurence of account sufficient pam_vas3.so # cat system-auth-ac ... account sufficient pam_vas3.so no_access_check ...


1

When you run something with sudo without specifying a particular user, you are running it as root user. As it seems you cloned your repository via SSH, git (actually SSH I guess) is looking for the SSH private key for the root user instead of the one of your user: /root/.ssh/ vs. /home/your-user/.ssh/. You can try the following: Run your script using sudo -...


1

Further research surfaced the sudo -S option which worked with some significant caveats. Below is what I used: for host in ...; do read -p "Password for $host sudo:" pswd; ssh leroy@$host "echo $pswd | sudo -S grep ^Jan\ 15 /var/log/{auth.log,auth.log.1,syslog,syslog.1}" > $host; done Caveats: The prompts can be confusing ...


2

With ssh ... 'sudo -S ...', without the -t, sudo would ask for the password from stdin, but couldn't disable the terminal echo for the password prompt. ssh doesn't set up a terminal on the remote by default if it's given a command to run. That's what sudo complains about. You could use the -t option have it do that... But as mentioned in the comments, that ...


2

You would simply tell sudo to forward the existing environment variable into the process it's spawning as root. See the --preserve-env=list option in man sudo. Also, running firefox as root gets, no questions asked, a very harsh No. Don't do that. There's positively no reason to run a browser as root, and whatever you're trying to solve that way must be ...


1

Your first line is wrong. Supposed to be #!, not $!. The former is a comment to your shell but tells your operating system which program you want to execute the script with, the latter contains the number of the last executed background job, if I remember correctly. Assuming there's no such thing, it would expand to nothing, so the start of your script just ...


2

You don't need to do anything special to the program: root can run programs as any user they want using e.g. su or sudo, as you demonstrate. But then that user needs to execute thee program. Hence, what you want is impossible, making a program be executed by another user, but not allowing that user to execute thee program. Your whole "change the ...


2

You can get case 3 by doing sudo -n true 2>/dev/null -- if it has nonzero status the cached authentication has expired (or been removed).


2

No, it's not "bad". What you have should work OK, but it's usually better to write a wrapper script to check arguments. For example, in /etc/sudoers: user ALL = (root) NOPASSWD: /usr/local/bin/suprogram and something like the following for /usr/local/bin/suprogram: #!/bin/bash if [[ $1 =~ ^[0-9]{1,4}$ ]]; then exec program "$1" else ...


3

What sudo does is it caches the credentials you've entered for 5 minutes, per user, per terminal session. For that, it simply writes an entry containing that data to /run/sudo/ts/username (or whatever timestampdir in sudoers points to), and checks it the next time you run sudo. Any other program with access to that file (i.e. needs to be run as root) can ...


0

Assuming the other username is testuser and the service is foobar.service, then you could run sudo machinectl shell testuser@ systemctl --user restart foobar.service References: "sudo and su do not create a login session" quote from https://www.redhat.com/sysadmin/sudo-rootless-podman https://stackoverflow.com/a/36873823/757777 https://github.com/...


0

I don't know what happened but I rebuild my base docker image again, and now the problem has gone away.


12

Your understanding of how tilde works is incomplete. See man bash and search for Tilde Expansion. It begins with (extra newlines and some bolding added by me): If a word begins with an unquoted tilde character (~), all of the characters preceding the first unquoted slash (or all characters, if there is no unquoted slash) are considered a tilde-prefix. If ...


0

I resolved this issue by updating the /etc/hosts file with the host information. Example 127.0.0.1 host1 host1.mydomain.com kali localhost


1

The sudoers file is not a shell, so you cannot use shell constructs in it. The closest I know of that you can get to, is to update sudoers (use visudo) each time you would have changed the contents of file.txt: Default badpass_message="some custom error message" As always when editing sudoers, (a) use visudo, and (b) have another root shell open (...


Top 50 recent answers are included