Tag Info

New answers tagged

2

tl;dr Access is determined by the user who is running application, and sudo runs applications as different user. Full version: How does the OS know that a command needs sudo? It doesn't know. UNIX manages permissions not on application level but on filesystem level: permissions are granted for users to access specific files. Applications then are run ...


1

This may be splitting hairs, but: to execute a file, you must have execute permission to the file and all the directories you navigate to get to the file.  So, if Tom has a program (do_interesting_stuff) in his home directory (/home/tom), and the directory is protected 700 (no access for anyone but owner) but the file is protected 755 (read and execute ...


3

su and sudo are privileged programs. su changes (after successful authentication) the real and effective user and group id to that of the user you su to. Thus, su is similar to login. Note that su can be used to change to any user, not just root. sudo also changes the real and effective user and group ids. Up to this point su and sudo are similar (but ...


11

Sometimes the "Permission denied" message is due to filesystem permissions denying you write access, for example. The executable/tool simply checks if it the filesystem grants you enough permissions to do what you're about to do and throws an error if it's denied by the filesystem. Other times, the tool itself will check your user ID before allowing you to ...


15

For the purposes you have described, the OS doesn't decide whether you need sudo to initially run the program. Instead, after the program starts running and then tries to do something that is not permitted by the current user (such as writing a file to /usr/bin to install a new command), the OS prevents the file access. The action to take on this condition ...


2

First the terminology. chmod is a program (and a system call) which alows changing permission bits of a file in a filesystem. sudo is a special program that allows running other programs with different credentials (typically with elevated privileges, most usually those of the root user). su is similar but less (read "not") configurable than sudo - most ...


0

You must edit your /etc/sudoers file and grant your user permission to run some programs as root without password: yourusername ALL = (root) NOPASSWD: /path/to/prog1, /path/to/prog2, ... In your case, you can try: myusername ALL = (root) NOPASSWD: /bin/mkdir, /usr/bin/touch, /bin/grep You must check NOPASSWD entry is the last entry that match your ...


2

As the 'Note:' hints at, this is usually caused by $PATH being set wrong. One way that happens is when you run dpkg -i without root; but that isn't the case here. An easy way to confirm the path is to run sudo -s, which tells sudo to run a shell instead of some other program. So you'll be landed at a root shell prompt. If you echo "$PATH", you'll likely ...


0

Although you don't have nosuid on your mount, it seems like your NFS client is defaulting to nosuid. You can change this by explicitly setting the suid flag. To do this live as root: mount -o remount,suid / If that works you can add it to your boot options. See also this Ask Ubuntu question which is pretty much the same problem you're having.


0

Check the permissions of the sudo executable. If you copied the files to another location, it may be possible that you lost the SUID bit on the file. $ which sudo /usr/bin/sudo $ ls -la /usr/bin/sudo ---s--x--x 2 root root 208808 Jun 3 2011 /usr/bin/sudo


4

Try: #!/bin/bash id touch script-run-user.file sudo -u appuser 'ksh' <<EOF # add list of cmds to execute id touch appuser.file EOF Edit: Just as an update, check out Here Documents. EOF = "End Of File", the name is arbitrary.


2

sudo -s Reads the $SHELL variable and executes the content. If $SHELL contains /bin/bash it invokes sudo /bin/bash. So, /bin/bash is started as non-login shell so all the dot-files are not executed, but bash itself reads .bashrc of the calling user. Your environment stays the same. Your home will not be root's home. So you are root, but in the environment ...


2

Verify that sudo is not aliased. Run like this /usr/bin/sudo /path/to/my/program For example a shell alias like this one: alias sudo="sudo env PATH=$PATH" may cause this behaviour.


1

Without sudo the command doesn't have privileges to capture the device: tcpdump: eth0: You don't have permission to capture on that device But with sudo it would, but being run after ssh, it never gets password input for sudo on the remote server, so the solution is use -S (man sudo) and pipe password for sudo as follows: ssh john@server-abc.com "echo ...


1

Set up sudo to preserve the HOME environment variable. Run visudo to edit the sudo configuration. Make sure that the option always_set_home is not set, and that HOME is present in the env_keep list. Add the following lines: Defaults !always_set_home Defaults env_keep+="HOME" Remove a line like Defaults always_set_home if there is one.


2

You can run this command via sudo on the server to capture the data first, and then send the resulting file back to your workstation to review the data sudo tcpdump -i eth0 -s 65535 -w /tmp/wireshark


0

Why don't you create a shell script and do a su - openproject -c "your_shell_script" Be aware of the - before openproject. That will set the environment variables of openproject instead of your user environment variables.


2

Use sudo -E to preserve your environment: $ export FOO=1 $ sudo -E env | grep FOO FOO=1 That will preserve $HOME and any other environment variables you had, so the same configuration files you started with will be accessed by the programs running as root. You can update sudoers to disable the env_reset setting, which clears out all environment variables ...


5

I agree with Valmiky that you're going about it the wrong way, but the sudoers line there isn't what I'd recommend. With his line, you are all authorized to sudo to anybody else including root without password. This effectively gives you full access to the server, meaning that the /bin/su part of the line is redundant. If you should only be able to sudo to ...


9

Do not do that! That will leave your password in your shell's history! If you really have to do that, what I recommend is that you configure your sudoers file to allow a passwordless login. To do that, run the command sudo visudo and add a line like this one: reddy ALL=NOPASSWD: /bin/su - * (where reddy would be your username). If you need to give this ...


0

It was an error in my PAM "auth" script: the script was terminating without ever getting an "ok" or "done".


1

Line 1: Mounts Types: NetworkFileSystem, SambaFileSystems, and CommonInternetFileSystems on All Shared Paths to the Users Home Directory, Along with: Mount All Devices as a loop, Along with Unmounting, all Saved in the Array MOUNTING. Line 2: Prints the kernel dump from the last successful boot, saved in the Array SYSTEMDIAG. Line 3: If the User is logged ...


3

This is what worked for me: USER_NAME=$(printf '%s' "${SUDO_USER:-$USER}") sudo -u $USER_NAME <command-to-exec-in-nonroot-context>


8

The sudoers file allows specifying commands to permit: username ALL=(root) NOPASSWD: /bin/foo bar baz Here username is the user you want to permit, and the command goes at the end of the line. If you specify arguments to the command, the user can only run it with exactly those arguments, but if you don't specify them here, the user can run the command ...


0

You can increase security by restricting the commands that a "sudo user" can run. This is highly recommended. This is the syntax on a Debian box I have, might be slightly different depending on the system. Cmnd_Alias USER_COMMAND = /bin/user_admin someuser ALL = PASSWD : USER_COMMAND This way someuser can only run the command /bin/user_admin as ...


1

As the other answerers said, this is the default behavior. If you really want to enter the root password instead of the user's password, you can add the line Defaults rootpw to your /etc/sudoers file (use the visudo command, do not edit the sudoers file by any other means). The usual disclaimer: The defaults chosen for sudo are the way they are for a ...


3

That's how sudo works. You trust the user and the user's actions are logged. If you want to enter the root password, then you want to use the su command as follows:- su -c yum install <package> Password: Once the command above finishes, you're returned to your normal user's prompt.


1

Well it is how it's done. You will grant the permission to users of group wheel to perform administration duties. In short you grant them root access. And this is not distro specific - in all Linux distributions and even BSDs you will do the same. If you're worried about compromising security you could remove the user from sudoers table and go with root. ...


5

No you're unable to find out whom has access to sudo rights if you yourself do not have access directly. You could possibly "back into it" by seeing what users if any are members of the Unix group "wheel". Example This shows that user "saml" is a member of the wheel group. $ getent group wheel wheel:x:10:saml Being a member of the "wheel" group ...


2

sudo From the relevant man page: The real and effective uid and gid are set to match those of the target user as specified in the passwd file. Also, in the description for the -P (preserve group vector) option to sudo: The real and effective group IDs, however, are still set to match the target user. Basically, whatever commands that are run ...


3

You can use suspend (as long as you invoked the shell with sudo -s instead of sudo -i): anthony@Haruhi:~$ sudo -s [sudo] password for anthony: root@Haruhi:~# suspend [1]+ Stopped sudo -s anthony@Haruhi:~$ If you invoked it with sudo -i, you can use suspend -f to force it to suspend anyway; note that you need to be careful there (as if ...


2

You should configure sudo security policy to allow user xyz exec something as user abc. Read 'man sudoers' and use visudo command to configure /etc/sudoers. For example let's allow user xyz exec /usr/bin/whoami as user abc without password. Add this string into /etc/sudoers (with visudo, don't edit /etc/sudoers directly): xyz ALL = (abc) NOPASSWD: ...


2

This is because sudo is different from su. When you su abc, you become the user abc as far as the system is concerned. You can then do anything that abc can do. On the other hand, sudo is used to allow other users to execute some commands by proxy. In other words, your sudo configuration allows you to do some commands on behalf of abc. If the command you're ...


1

From: http://www.sudo.ws/sudoers.man.html username ALL=(ALL:ALL) /some/random/command should allow username to run /some/random/command as any other user (including root) from any host. No one but username would be able to run that command if that is the only rule in the file. Make sure there's not another rule that says "user" or "group" can run ...


0

You probably have no graphical tool installed which asks for your sudo or root password before running a tool which needs these permissions. apt-get install gksu should do the trick.



Top 50 recent answers are included