Tag Info

New answers tagged

3

Removing vim-minimal was a mistake. If you intend to make use of sudo you have to have that package installed on Fedora. You can tell that sudo requires it like so: $ rpm -q --requires sudo | grep vim vim-minimal I'd suggest putting it back, and working around whatever the other issue actually was with vim. Fedora has always had excellent support when it ...


2

Ok, if anyone ends up in a similar situation, you can use pkexec yum install sudo. pkexec will let you enter your password in your OS's GUI. 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. This helped: ...


0

The normal way works nicely for me: $ sudo -u test -n true sudo: a password is required $ echo $? 1 $ sudo -u test -n true >/dev/null 2>&1 $ echo $? 1 But if for whatever reasons it does not help for you, try these: $ { sudo -u test -n true ; } >/dev/null 2>&1 $ ...


0

Sudo creates an environment variable "SUDO_USER" that you can use to find out the user who logged in (actually who ran Sudo). Assuming you Sudo to root (it is possible to use Sudo to access other users too), you can write a script to automate the following two steps. cp source target chown $SUDO_USER target (This won't work if you sudo to a non root user ...


8

If you don't want to be challenged every time for your password then I'd recommend setting it to NOPASSWD in your /etc/sudoers file rather than hardcode your password in your logins. At least this way your primary login's password will remain intact and not be completely exposed in your .bashrc. To make this change run the command sudo visudo, and change ...


4

This is actually configuration-dependent. There is an env_reset option in sudoers that, combined with env_check and env_delete, controls whether to replace, extend, or pass through some or all environment variables, including PATH. The default behaviour is to have env_reset enabled, and to reset PATH. The value PATH is set to can be controlled with the ...


5

When running sudo under a user login session, will that change $PATH to be the root's $PATH during the running of sudo ? sudo will change $PATH variable, depend on your security policy. From sudo man page: PATH May be overridden by the security policy. In most system, env_reset option is enabled by default, this causes commands to be ...


5

Do you need to get an interactive login root shell? sudo -H -i from man sudo: -H The -H (HOME) option requests that the security policy set the HOME environment variable to the home directory of the target user (root by default) as specified by the password database. Depending on the policy, this may be the default ...


0

Piotr gave a very good explanation of how sudo works. However, he didn't really motivate why it works this way, so I'll try to add that here. Before the sudo command was created, we had the su command. This command allows one user to execute commands as another user, usually root (as with sudo, this is the default target user). It was totally ...


7

If you do: sudo cat /etc/foo.txt > ~/foo.txt Then ~/foo.txt will be open by the shell as you (so created with your credentials), and then sudo will be executed with its stdout redirected to that. In the end, the file will be owned by you. That kind of approach also helps limiting the things done by root. Here, root only uses his privilege to open ...


1

You can also set the default PATH at /etc/sudoers edit the file using visudo and update the line to what ever you wish: Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin


14

With a POSIX-compatible cp you can sudo cp -p foo bar to preserve the following file metadata when copying: Access time Modification time User ID Group ID Mode If you want to set a different user JennyD's solution is best.


30

Use install instead of cp: sudo install -o belmin /etc/foo.txt ~/foo.txt


3

Using sudo, you switch to another user. That's the whole point of the command. I assume you don't have any regular access to the first file, so you need to be another user (root in this case) to gain access. There's no way for sudo itself to manage that, since all sudo is doing is switching you to the other user to execute the command. You will need to ...


1

If you fiddled with your home directory, you needed root to get at the /home directory that contains it. Possibly your home now contains some stuff owned by something other than you, that the sudo obviates. An aggressive approach might be "sudo chown -R myname:users ~myname" A more cautious person might do "find ~myname ! -user myname" to look for such ...


1

First, disabling an account is usually done by setting the encrypted password to *, which is not the encrypted value of any string. I can't check right now, but I believe that's what Ubuntu does for root as well. So technically, there is no root password on Ubuntu. But sudo precedes Ubuntu; it was designed for systems where there certainly were root ...


3

The answer to your question is: When you run a command with sudo, you run the command with elevated priviliges, that is root priviliges. You only have to type your normal user password because you (the user) has been added to sudoers file which gives you root priviliges.


13

The whole point of sudo is to grant you someone's else privileges (usually root) without asking for this other account's password (unlike su). sudo is asking here for your password just to make sure a passerby won't misuse your unlocked terminal. Ubuntu and many other Linux and Unix OSes are granting an initial account created at installation time the ...


55

In details it works the following way: /usr/bin/sudo executable file has setuid bit set, so even when executed by another user, it runs with the file owner's user id (root in that case). sudo checks in /etc/sudoers file what privileges do you have and whether you are permitted to run the command you are invoking. Saying simply, /etc/sudoers is a file which ...


0

I don't think that sudo recognizes AD windows groups.


1

From my look at man 5 sudoers, this might be intended for the case you distribute or share the same sudoers file over several machines, effectively making part of the file conditional on your hostname. So, you still have to have this sudoers file on 192.168.1.14, but it would not give you rights on .1.15.


5

On Debian derived systems you can get the source (even as a non root user) using apt-get source provided sources.list has some deb-src entries. Otherwise it's stuck with downloading from the project source repository with standard tools. Once you've got that source then: ./configure --prefix=/home/me/mysoftware make make install Will work for most source ...


0

Without repeating what's already been answered, you could take a look at http://askubuntu.com/questions/339/how-can-i-install-a-package-without-root-access. That appears to be the answer to your question.


7

Yes. If your user account is compromised (as in someone/something else can run arbitrary commands in your name), then they can for instance modify your ~/.bashrc and add something like: alias sudo='sudo sh -c '\''install-my-backdoor; exec "$@"'\'' sh' so that when you run sudo apt-get update, it actually runs sudo sh -c 'install-my-backdoor; exec "$@"' ...


-4

No. Sudo is not a mode of the computer. Sudo executes the specified command with root privilege. Malware can only get in if you use sudo to execute the malware or if the apt-get executable has been compromised. Of course apt-get is protected and requires root privilege to modify. Notice that if you bring up two terminals and enter sudo su to operate in the ...


0

Aliases and functions are defined in a shell. Sudo is an external program. So sudo doesn't see aliases, functions or shell builtins, only external commands. Aliases are meant to be alternate command names, so shells only expand them in command position, not when they're arguments to commands. Zsh supports global aliases, which are expanded anywhere on the ...


3

This happens because you're only running the echo command as root. The output redirect is handled by your (non-root) shell. To avoid this, don't use the shell's redirect and use an actual command to handle the writing: tee. What you want to do can be done as so: echo "xyz" | sudo tee test > /dev/null (if you don't redirect the output, tee will output xyz ...


3

I see the below information from here. When using sudo, use alias expansion (otherwise sudo ignores your aliases) alias sudo='sudo ' The reason why it doesn't work is explained here. Bash only checks the first word of a command for an alias, any words after that are not checked. That means in a command like sudo ll, only the first word (sudo) is ...


2

Edit your /etc/sudoers, add this line (or edit if it's existed): Defaults !tty_tickets fish somehow thinks command is from separated session. It's maybe due to tty's modification date as reported by stat is changing under fish. This was caused by fish's futimes() call See more details: fish issue #122 Disable futimes()


0

Use a wrapper around renice, something like: #!/bin/sh priority="$1" pid="$2" owner=`ps -h -o uid $pid` if [ $owner != ${SUDO_UID} ]; then echo "Only your own processes can be reniced" >&2 exit 1 fi renice $priority $pid Note, that the example is fragile and prone to race conditions because of the delay between the ownership check and the ...


1

So as you said yourself @krzysto, the solution is to add the following to the sudoers file beans ALL = (root,apache) NOPASSWD: /usr/bin/ksh -c /opt/renovations/var/script-*.sh beans ALL = (root,apache) NOPASSWD: /usr/bin/bash -c /opt/renovations/var/script-*.sh The next piece that is missing is to make sure that the group has execute permissions on the ...


0

You want group members to be able to only renice their own processes. This is the default behaviour without a sudoers entry. By default they can renice their own processes` nice value within the range 0 - 19. Having sudo access to renice allows them to increase this range from -20 to 19 as well as renice processes not owned by them. Running man renice, I ...


1

TL;DR. I found out where the problem lies! I had to sleep some time between some of the partitioning tasks. Apparently I stumbled upon concurrency issues. In-depth: It looks like when a process completes, it doesn't mean that kernel has already completed it's role in the process (in case kernel has to do something after given process). In my case, that ...


0

Maybe you are using vi to try to start VIM which will not use /etc/vimrc. If that is the case, you have two options: Use vim Modify /etc/profile.d/vim.sh to set vi as an alias for all users not only for users with a uid >= 100


1

This also works well: :w !sudo sh -c "cat > %" This is inspired by the comment of @Nathan Long in this answer. NOTICE: " must be used instead of ' because we want % to be expanded before passing to shell.



Top 50 recent answers are included