Tag Info

New answers tagged

1

As openvpn needs root privileges to set routes or ip addresses for an interface it is very uncommon to run it as a user, if possible at all. But the command not found is a simple PATH topic. Check sudo which openvpn where root calls the binary. Normally openvpn lives in /usr/sbin, a location for daemon programs, that are started as root and possible ...


0

If you can't edit /etc/sudoers file. follow this. it worked for me. cd /etc sudo su visudo -f sudoers


0

You don't those /dev links to do this. I know sudo will purge environment variables, but you can still pass variables through in the form of arguments since you're calling another shell anyway... sudo -u nobody bash -c ' a=$1; echo "$a" ' -- "$(echo aaa)" ...or... echo aaa | { sudo -u nobody bash -c ' a=$1; echo "$a" ' -- ...


0

First, my suggested solution is presented below. After this, each of the two errors that you observed are discussed. Suggested Solution Bash variables cannot hold a NUL character. Consequently, it is only possible to read an entire file into a bash variable if the file contains no such characters. Subject to this bash limitation, the following should ...


0

There's actually a fairly simple way to do this, by creating a Bash (or shell of your choice) script to restrict the modifications made to a particular file or directory. In your example, it would look like this: $ vi /usr/local/bin/mychmod #!/bin/bash chmod 777 /var/www/index.html Then you would change the sudoers file to allow www-data to execute ...


1

Quick answer: Install bash-completion Source bash_completion on Bash startup Add your compspec on Bash startup Don't overwrite sudo compspec with complete -cf sudo I suppose that you use MacOSX with brew. Try: brew update brew install bash-completion brew info bash-completion # bash-completion: stable 1.3 . $(brew --prefix)/etc/bash_completion complete ...


0

Sorry I forgot to mention that I resolved this problem a very long time ago thanks to Arul Selvan. His solution is the solution to the issue I had and possibly anyone else may have... Cheers/Kudos/Thanks


1

winbind and sssd import the AD groups in an equivalent manner to NIS netgroups. So your group definitions in the /etc/sudoers file need to start with + and not %. Furthermore, names containing spaces should either be double-quoted, or each space specified as \x20. %sudo ALL = (ALL) ALL +"domain users" ALL = (ALL) ALL +domain\x20admins ALL = ...


1

Several months after you asked but the correct answer is that you remove all domain information from the group. All the information is set and extracted by SSSD automatically. The only flaw I see in some of your examples is that you escaped the space with a ^. An AD group of Enterprise Admins would have a sudoers line that starts with %Enterpirse\ Admins ...


2

I'd personally make no assumption on sudo, just as putting sudo in a script is a bad idea. Your fourth suggestion (check whether the script runs as root) is best, IMHO. Just that I prefer checking the effective user ID instead of its name: [ -n "$EUID" ] && [ $EUID -eq 0 ] || <not root, exit> This will leave the choice to the user, which ...


0

The difference between ALL:ALL and ALL in RunAs is the combinations of user and group that can be used. For example: # sudo -u muru -g git id Sorry, user root is not allowed to execute '/usr/bin/id' as muru:git on muru-laptop. # sudo -u muru -g muru id uid=1000(muru) gid=1000(muru) groups=1000(muru),10(wheel),21(locate),102(polkitd),190(systemd-journal) $ ...


1

Eplanation for %sudo ALL=(ALL:ALL) ALL:- %sudo - the group (named sudo) allowed to use sudo. 1st ALL means to allow sudo from any terminal, or from any host (on any machine) (ALL:ALL) indicates command can be run as (User:Group) Last All means all commands can be executed Explanation for root ALL=(ALL) ALL root - the user (root) allowed to do ...


2

I suspect there's no myip recorded in /root/.ssh/known_hosts. Please try once sudo ssh root@myip interactively before running that script. Alternatively, you can disable host key checking: #!/bin/bash -v sshpass -p '<pypasswd>' scp -o StrictHostKeyChecking=no blah.img root@myip:/home/user/blah.img exit 0


1

Your root user doesn't have the same private keys that you are using when not running as root. Therefore, as root, you cannot copy the material. Try copying adding ~/.ssh/id_rsa to /root/.ssh/id_rsa (or some other private key you are using to connect to myip). Alternatively let the sudo do the other things, and change back to the "normal" user in the ...


-1

To restrict the sudoers from mounting, modify your sudoers file as in, #limit users in group 'sudo' from mounting %sudo ALL=(ALL) ALL, !MOUNT To protect a directory from a sudoer, you can try setting using ACL, further information can be found here, I am not sure this will work since sudo is almost a root access Setting Access ACLs


1

In some distros, Manjaro in my case, there is a file that overrides the /etc/sudoers file sudo cat /etc/sudoers.d/10-installer the ONLY way to see it is under root privilegies, you cannot list this directory without it. There you will find something like this: youruser ALL=(ALL) You can delete that file, and will use cfg in /etc/sudoers file ...


0

You can also just create your user as normal, then login as root and add this in /etc/sudoers: youruser ALL=(ALL) ALL This says youruser can sudo and run any command as root without being prompted for a password on each command. If you look at /etc/sudoers after running the command posted by Christopher, you will probably find that command created a ...


0

If your regular username is john: $ su - # apt-get install sudo # usermod -a -G sudo john # logout $ logout $ indicates a command executed as a regular user. # indicates a command executed as the user, root. Log in again as john and execute sudo -i to test.


1

I tend to use:sudo su - USERNAME and then do what you need as that user. To quit just type exit


0

It's possible via editing your sudors file . lnydex99uhc:~ user$ ls /etc/sudoers /etc/sudoers Fistly , run the below command to print out the current sudo configuration. sudo -ll | column -t Example Entries To allow a user to gain full root privileges when he/she precedes a command with sudo, add the following line: USER_NAME ALL=(ALL) ALL To ...


1

It is possible using sudo. Use %<group-name> for the RunAs list. For example, with the following rule: sysad ALL = (%wheel) ALL And the following group configuration: $ getent group wheel wheel:x:10:root,muru We get the following amusing effect: $ sudo -u sysad bash -c 'echo $USER' Sorry, user sysad is not allowed to execute '/usr/bin/bash' as ...


1

What did you use to create the user? My preliminary test shows that a simple useradd <login> visudo # in visudo <login> ALL=(ALL) NOPASSWD: ALL # save and exit visudo # as another user $ sudo -u <login> hostname -f $ sudo -u <login> -s Should work without any further problems, what does the asterisk log tells you ? Did you by ...


5

The error message tells you what is wrong even if it doesn't tell you exactly how to fix it. adminvpn is not in the sudoers file. sudo lets you run commands as the administrator. In order to be able to use sudo, you need to be made an administrator. Accounts are not made administrators by default. Run the command visudo (as root, of course) and add a ...


1

sudo su && cp /home/sk/keys/master.pem /home/sg-user/keys/ This runs the command sudo su. sudo su runs an interactive shell as root, it is basically equivalent to sudo -s or sudo bash (if your shell is bash). Once this command has finished, if it returned a success status, the cp command is executed as the original user. As far as the shell is ...


2

When commands are run they split into a child processes, so when the 'su' command runs it's going to run in a separate process to the cp command and not actually within the root terminal. The command will work if you run cp with sudo, but it's not going to run inside the root terminal, you'd have to run the commands separately within su to accomplish that. ...


1

You should try sudo cp /home/sk/keys/master.pem /home/sg-user/keys/


0

One thing that could explain the difference is if you're ending up with different limits for the maximum realtime priority (ulimit -r). Root cannot exceed the limit, but can raise it. Check with ulimit -r (or, in C, with getrlimit(RLIMIT_RTPRIO, …) and raise the limit before running your program if necessary. If that doesn't help, it's probably a problem in ...



Top 50 recent answers are included