Tag Info

New answers tagged

0

The following in /etc/sudoers should give you per-user rather than per-user-per-tty credential caching: Defaults !tty_tickets According to the sudoers man page, sudoers uses per-user time stamp files for credential caching. Once a user has been authenticated, a record is written containing the uid that was used to authenticate, the terminal ...


0

If this is for a daemon, the standard way of doing things is to put something like this in the init script file: USER=bob ... su -c '/command/to/start/actual/daemon' "$USER" In the script file that should be run as bob, just put sudo in front of the pertinent commands. Also, make sure you read this about enabling alias expansion in non-interactive Bash ...


1

You sudo the command command, the redirection of the output to /some/file.log is done by your current shell, which is running as the normal user. What you could try in order to get the output written by root is: sudo bash -c "command > /some/file.log"


3

The last string should be FOOEMPLOYEES ALL = (ALL) NOPASSWD: FOOCOMMANDS From the man sudoers The basic structure of a user specification is “who where = (as_whom) what”


0

How about gksudo? $ gksudo your_app_launcher.sh It does show a graphical dialog for safely entering the administrator password.


0

Any time you are going to sudo rm things, you should gravely consider what you are doing if you are not using explicit paths. sudo rm /explicit/path/to/directory/* should work. You will still get that error if there are not files in directory; you can suppress that with rm -f (not rm -fr unless you are absolutely certain of what you are doing).


5

You're having problems because your shell is trying to expand * into the list of files, but it can't since you don't have rights to read the directory. I can think of two things that would work sudo bash -c "rm directory/*" In this case, the * isn't expanded by you, but by root, who can read the directory OR sudo find directory -type f -exec rm {} \; ...


3

The ifconfig command is not included in users PATH env variable. So you can either /sbin/ifconfig or modify the PATH variable to include sbin into your users path. Add the following line to your ~/.bashrc export PATH="$PATH:/usr/local/sbin:/usr/sbin:/sbin" source ~/.bashrc using, . ~/.bashrc or source ~/.bashrc or open e new terminal which will source ...


3

You could add sudo -l to the allowed commands for all users. Edit the sudoers file with visudo and add a line like this: ALL ALL=(ALL) NOPASSWD: /usr/bin/sudo -l When a user now calls sudo -l the output looks as follows: User foo may run the following commands on this host: (ALL) NOPASSWD: /usr/bin/sudo -l Unfortunately the user has not no ...


3

The sudeoers file is usually located at /etc/sudoers. You need administrative privileges to edit this file. Editing it directly is strongly discouraged: you could irrevocably damage your system in case of syntax errors. The visudo tool is provided with the sudo package for safe editing. It will automatically check file's consistency before saving and abort ...


1

The command sudo is a frontend program that takes arguments, switches and commands. Most commands can take arguments & switches, but some can take other commands to run. Think of them as wrappers if you will. So sudo will create an entirely new instance of Bash (with elevated privileges as root), and then run the command you provided it. So in this ...


17

The reason is simple, cd is a shell builtin (and shell function in some shells), while echo is both a binary and a shell builtin: $ type -a cd cd is a shell builtin $ type -a echo echo is a shell builtin echo is /bin/echo sudo can't handle shell builtins, but can handle binaries in the $PATH. When you use sudo echo, /bin/echo is found in the $PATH, so ...


1

The issue is more for sudo cd to fail on your OS than sudo echo to succeed. sudo cd /directory is quite a legitimate method to check if a given user, likely root here, is allowed to cd to some directory. That is the reason why all Posix compliant OSes do provide an executable version of cd. So the answer to you question is sudo echo yo works by design ...


3

running which echo gives /bin/echo echo is a plain program, and sudo can "find" it. On a side note, there must be some option in sudoers(5)


2

It does work, just not how you expect. && waits until the command before it completes. If the result at that point is true, it will execute the next instruction. So if you type bash && cd desktop, you will first be presented with a bash shell. If you type exit, you'll be back in whatever shell you were in before, and then the directory will ...


2

There are two options, comment out the Defaults requiretty setting from /etc/sudoers as you mentioned or use the pseudo-tty allocation (-t) argument for ssh. Try the following in your jenkins script: ssh -t 127.0.0.1 "sudo command" Although you will have to have ssh pre-shared keys configured to yourself and run it once manually to add an entry to ...


19

The part after && is executed in the current shell, it is not some argument handed over to the bash you run with sudo. You might be tempted to try sudo bash -c 'cd desktop' but that doesn't work because that bash exits after cd desktop. You can try: sudo sh -c 'cd desktop && exec bash' which "works" (i.e. places you in the directory ...


5

That is certainly incorrect. Sudo originated around 1980¹ Debian was first announced in 1993. ¹ I used sudo myself as early as the 80s before Linux was first released let alone Debian.


0

Run sudo visudo and comment out the two lines shown below. Commenting out only env_reset does not work #Defaults env_reset Defaults mail_badpass #Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"


6

There are two commands related to root privileges, SUDO and SU. With SUDO, you don't become another user (including root). SUDO has a pre-defined list of approved commands that it executes on your behalf (this addresses what I asked in the comment about how you give selected users selective privileges). Since you are not becoming root or another user, you ...


2

Short answer is you can't. If you allow someone (e.g. simth) in sudoer's group, he can issue a sudo su - then become root, then anoter user (e.g. wesson). This is an alternate way of giving root's password to simth. However he (smith) can change root passwd. Notes also that 1) you must specify in /etc/sudoers a line like %sudo ALL=(ALL:ALL) ALL 2) ...


11

The major difference between sudo and su is the mechanism used to authenticate. With su the user must know the root password (which should be a closely guarded secret), while with sudo the user uses his/her own password. In order to stop all users causing mayhem, the priviliges discharged by the sudo command can, fortunately, be configured using the ...


0

As DopeGhoti mentions, sudo asks for your user password, not the root password. If you have neither the root password nor the password of an account that has sudo rights, your next best bet is to reboot the server into maintenance mode, or if that doesn't work right, boot with init=/bin/sh as part of the kernel command line to change the root password.


-2

Maybe you have not set your root password. Try running: $ sudo passed


2

It is usually your personal login password. For example: derek$ sudo ls /var/log/secret [sudo] password for derek: <type derek's login password> audit.log audit.log.1 audit.log.2 This can be altered by policy files such as /etc/sudoers. See for example Set sudo password differently from login one


0

In order to be able to execute commands as root, you have to be listed in the sudoers file. You should edit the sudoers-file with the visudo-command: Edit the visudo-File as root : visudo Navigate to the section # User privilege specification (Not really a section, but you should keep the layout..) Hit the Letter 'i' to get into the INSERT-Mode Add the ...


0

The changes will take effect as soon as you log out and log back in again. If you do that or simply reboot, everything should work as expected.


0

Gnome 3 uses an authorization mechanism called polkit so the right way to run that executable as root is via pkexec: pkexec allows an authorized user to execute PROGRAM as another user. If username is not specified, then the program will be executed as the administrative super user, root. To authorize the user in the active session to run that ...


0

I think you need to use gksudo in this case. I quote from the gksudo(1) man page: gksu is a frontend to su and gksudo is a frontend to sudo. Their pri‐ mary purpose is to run graphical commands that need root without the need to run an X terminal emulator and using su directly So it would seem that the issue here is that the ...


0

is_readable /path/to/file is spelled test -r /path/to/file or [ -r /path/to/file ] or [[ -r /path/to/file ]]. See using single or double bracket - bash for how they differ. is_writable uses -w. Not being able to access a file is not a very good indicator of “needing sudo”. It may be that you should run as a different user or group, not as root. It may be ...


2

You can try the -w switch of the test utillity: [ -w /path/to/file ] && do_command /path/to/file || sudo do_command /path/to/file Or the long version: if [ -w /path/to/file ]; then do_command /path/to/file else sudo do_command /path/to/file fi From the manpage -w FILE FILE exists and write permission is granted



Top 50 recent answers are included