New answers tagged

0

Disclaimer: IMHO, this is a very bad idea. You should not erase the password of an account. As explained here, you have to disable the password check in sudo, editing the sudo configuration file. Note that the order is important. You have to change sudo configuration before to erase the password. If it is to late, you can simply set a new password, change ...


0

Have you added yourself to the sudoers group by amending the /etc/sudoers file? See: https://wiki.centos.org/TipsAndTricks/BecomingRoot


2

sudo wants your password in your case user cooltoo's password, not the root password. Update You don't need to be root every time you want to run some specific administrative tasks. Thanks to sudo, you can run some or every command as root. Once sudo is installed (package name: sudo), you can configure it by running visudo as root. Basically, it runs ...


0

I've been using the form username ALL=(ALL) NOPASSWD: /bin/su targetuser


1

You can use... echo password | sudo -S recover.sh Password being your sudo password. From sudo manpage.. -S, --stdin Write the prompt to the standard error and read the password from the standard input instead of using the terminal device. And second method is sudo -S <<< password apt-get install pkg_name


1

If you don't want to enter password manually you use -A option of sudo -A, --askpass Normally, if sudo requires a password, it will read it from the user's terminal. If the -A (askpass) option is specified, a (possibly graphi‐ cal) helper program is executed to read the user's password and output the ...


0

Ok, I think I found the problem. Apparently it was sqsh that was adding those '|' characters. sqsh has a style (-m) flag and it seems if you don't set it explicitly then it defaults to the 'bcp' style which adds those extra characters. What I would still like to know is why it defaults to one style 'bcp' when run with sudo but defaults to another style ...


3

Process substitution <(…) creates a pipe, uses /dev/fd to give a path that's equivalent to the file descriptor where the pipe is, and passes the file name as an argument to the program. Here the program is sudo, and it passes that argument (which is just a string, as far as it's concerned) to wpa_supplicant, which treats it as a file name. The problem is ...


2

sudo uses the system resolver, configured by /etc/nsswitch.conf; in your case, host lookups were configured to use /etc/hosts, which had the previous hostname identified with the server's IP. To fix it, simply update /etc/hosts with the new hostname.


3

Quoting the ArchLinux wiki: Note: Because of the process substitution, you cannot run this command with sudo - you will need a root shell. You should be able to use su -c under sudo like so: $ sudo su -c 'wpa_supplicant -D nl80211,wext -i wlp4s0 -c \ <(wpa_passphrase "some ssid" "password")'


0

sudo is great, but sometimes it is not the best fit. For this I like to use super. super also allows elevated permissions, however it assumes command aliases, which is convenient when allowing complicated command lines, because they are used as simple command lines. your super.tab would look like: grepcmd "grep 'string I want (' /var/log/thefilename.log" ...


1

Since you only need root for the file access, consider using cat, tee or something similar and piping that to grep or whatever program you need to run. E.g. sudo cat /file/path | grep … This way you restrict root to where you absolutely need it.


1

Well, you know that if you call sudo and it asks for your password you can't see it when typing. sudo does this by disabling echo, which means that it disables the shells functionality to write on the screen until you finished writing your password. Now there are certain situations in which sudo can't disable echo, one example is given in the manpage. By ...


5

Apparently, sudo flattens the command into a string before comparing it to a specification in the sudoers file. So, in your case, you don't need to use quotes or any other form of escaping: user ALL=(root) NOPASSWD: /bin/grep string I want ( /var/log/thefilename.log Edit: As @user23013 points out in the comments, this can be exploited to grep for "string ...


19

Write a script (writeable only by root) In that script, execute the grep you need In the sudoers config, allow only access to that script Configure whatever tool or advise whichever user to just run the script via sudo Much easier to debug, easier to lock down specific access to a specific file, and much harder to exploit.


0

Not sure if this can be used by sudo (probably yes, somehow) and it requires X display: Certainly it works with ssh as demonstrated on the picture above. It is taken from Fedora, but I hope other distros have something similar.


2

sudo sanitizes environment before running any command, so unless you save the desired environment variable in /etc/sudoers using env_keep the varible will not be preserved by sudo. Alternately, for a single command, you can do: sudo LANG=en_US.UTF-8 some_command In order to preserve the current environment: sudo -E some_command


1

Giving visual feedback for every character entered would by definition reveal the number of characters typed, so by that metric, no, there is not a way to simultaneously do a thing and not do it.


0

This seems to have been overlooked: Defaults umask_override which does what was asked (see the sudoers manpage): umask_override If set, sudo will set the umask as specified by sudoers without modification. This makes it possible to specify a more permissive umask in sudoers than the user's own umask and matches historical behavior. If umask_override ...


1

cat /etc/hosts | ssh samba2 'sudo tee /etc/hosts > /dev/null' The tee is running as root, so is able to overwrite /etc/hosts with stdin. throw away tee's stdout because we don't need/want to see it. And no need to jump through any hoops for unusual quoting. If you need to append (as in >>) instead of overwrite, you can use tee -a.


2

ssh -tt samba "sudo bash -s" <<EOF echo "$(cat /etc/hosts)" >/etc/hosts exit 0 EOF this will open a session and run an elevated bash with the heredoc passed as script the -tt argument is for ssh to allocate a pseudo tty or else sudo will complain, in the heredoc the command substitution will take place locally and the full text will get ...


1

The redirection as given will not work, but you can do this in two steps: copy the file using scp update the file on the remote machine using sudo For instance scp -p /etc/hosts samba2: ssh -t samba2 sudo cp -f -v -p ~/hosts /etc/hosts which attempts to preserve the permissions of the copied file. Depending on the system you are using, the -p option ...


1

The problem with: sudo -u secondUser cp /home/firstUser/file /home/secondUser is that as soon as you become secondUser, you don't have access to /home/firstUser/file. The solution is you need to open the file for secondUser as firstUser and have secondUser inherit that file descriptor. As a security measure, sudo will close all file descriptors except ...


1

The problem here is that: secondUser doesn't have access to your home directory. You don't have access to secondUser's home directory. As such, regardless of whether you run the cp command as yourself or as secondUser, it can't perform the file copy. Given that you said you don't have root access, the obvious answer is to copy the file through an ...


0

The -u flag to sudo will allow you to specify the user account under which a command should run, but will require you to know the other user's password. sudo -u secondUser cp file /home/secondUser/file If you do not know the password of the other user, you may not be able to do this. This is part of the normal privilege separation design of the system, ...


0

Copy the file to /tmp and change permissions to 777. su to the second user. Copy the file from /tmp. The command sudo secondUser is not valid.


0

You can do su secondUser and then do stuff as the 2nd user.


0

Another approach is to configure PolicyKit to allow members of a particular group to reboot; that is, being authorised directly thus avoiding the whole question of satisying authentication to gain the superuser's authorisation. Create a file /etc/polkit-1/localauthority/50-local.d/50-local.pkla and add a clause like: [Allow reboot by booters group] ...


2

sudo is a command that executes whatever command follows as another user (if no username is given like in this case, that user is root) - to be able to do this, the account from which sudo is being executed needs to have the necessary permissions setup (see /etc/sudoers) su starts a new shell under a different user id -s /bin/bash specifies the shell to be ...


0

I guess it would use your sudoer ability to get a bash with the foo user. It wouldn't require foo's password because with sudo you are using root's permissions or something.


0

The threat of repeatedly failed sudo access attempts is that a malicious user might be able to brute force the password and thereby escalate their privileges. Since the user in question doesn't actually have sudo access, this is a dangling threat – a threat with no vulnerability to exploit. However, a monitoring system might trigger an alarm for this as part ...


1

Create a file like the following: #!/bin/sh USER=u PASSWORD=p IP=10.10.10.10 node app.js ... or ... #!/bin/sh USER=u; export USER PASSWORD=p; export PASSWORD IP=10.10.10.10; export IP node app.js ... where you put your own values in there instead of "u", "p", and "10.10.10.10". Save the file as, say, runapp, then make it executable with chmod u+x ...


3

You need to run export against the name of the variable. Right now, the variable is being referenced and replaced before export sees it. Change it to this: export user Note the lack of $ Your current version is essentially this: export ubuntu Because $user is interpreted first. You also lost your environmental variables when using sudo. There are ...


0

If a malicious user got access to your login and you have unrestricted sudo access, you are correct: sudo access wouldn't provide any additional barrier compared to just using a root shell directly. (That's likely the first thing they would do with their sudo access anyway.) However, if it's just you using it, using normal privileges except when you ...


0

I suspect that the system reports each failed sudo attempt to the sysadmin, who takes them as individual action items. Yelling at you allows the sysadmin to cross them off his/her todo list. The threat model is not to the system, but to the sysadmin. The sysadmin feels a need to respond to these incidents to prove that s/he is not asleep at the wheel. If ...


3

I can't speak to your specific situation; you'll have to ask your sysadmin why they chose to yell at you. But I can tell you why sudo reports these incidents: Because there is no legitimate reason for them to happen. You do not have root. You should know that you don't have root (and if somehow you don't, you can check with sudo -l). You have no business ...


7

I was trying to follow some linux instructions that involved sudo This is the threat. A user who doesn't know or understand what he or she is entering into their terminal with sudo privileges can cause very bad things to happen very quickly. It sounds like the admin didn't really explain to you that trying to sudo isn't really the issue, (in theory you ...


2

If sudo is configured to send email and if the mailbox file hypothetical failed sudoers email goes to (or if the MTA is broken, the mail queue) is not or seldom monitored, and if a malicious local user is given sufficient time, and if disk usage on /var is not monitored, then a malicious local user may be able to fill that partition with mailbox or mailqueue ...


14

First off, sudo all by itself, doesn't send any emails or create warning messages, other than logging your unsuccessful attempt to the log. People who observe these logs and correlate events (most probably using a scripted log watcher), see that some user id, which happened to be yours this time, is trying to gain root access where he/she is not permitted. ...


1

So the reason that you're backup is failing as a normal user is because the libdata file that mysqlbackup is attempting to copy/backup is owned by a different user (more than likely, 'mysql') or a privileged user. So, running mysqlbackup as an elevated user is probably the right choice here as you're attempting to do. I surmise that the reason you aren't ...


1

Probably secure_path is set in /etc/sudoers. The path shown by which mysqlbackup is not included there, but it is shown in echo $PATH when run as your user or from a root login, right? It does seem odd though.


2

short answer : You can't execute arbirary admin command without either a sudo or being root. long answer : You must either have NOPASSWD in /etc/sudoers, or log as root. (see http://askubuntu.com/questions/147241/execute-sudo-without-password ) visudo then add a line username ALL=(ALL) NOPASSWD: ALL


1

If /etc/sudoers allows your user to run ANY command as root (and not just a limited pre-defined set of commands) then you can run sudo -i to get a root login shell. You'll be able to run commands as root until you exit that shell, without having to preface every command with sudo. e.g. $ sudo -i # id uid=0(root) gid=0(root) groups=0(root) # ...


1

While OP might have a good reason for wanting to do exactly this, it usually is a bad idea (password can be read by ps, and so on) and I wanted to provide a more secure alternative. A better solution if you want to run something with sudo without putting in your password is to allow your user to do exactly that one command without password. Open sudoers ...


3

sudo does not have an option to specify the password, but you can still do the authentication on the command line, like this: echo password | sudo -u root --stdin or just echo password | sudo -S referring to the sudo manual page: -S, --stdin Write the prompt to the standard error and read the password from the standard input instead of using the ...


6

For this case, there is a line in manual page for sudoers: The sudoers file should always be edited by the visudo command which locks the file and does grammatical checking. It is imperative that sudoers be free of syntax errors since sudo will not run with a syntactically incorrect sudoers file. It is not in your question, but now there are two ...


0

Its fixed!. Steps taken 1. root@localhost james]# umount -v /dev/sdf2 umount: /run/media/james (/dev/sdf2) unmounted 2. cd /run/media/james 3. mkdir MEDIA 4. vi /etc/fstab 5. Edited fstab with /dev/sdf2 /run/media/james/MEDIA ntfs-3g defaults 0 0 6. mount /dev/sdf2 Big thanks to the CENTOS community!


11

According to the sudo man page: -l, --list If no command is specified, list the allowed (and forbidden) commands for the invoking user (or the user specified by the -U option) on the current host. A longer list format is used if this option is specified multiple times and the security policy supports a ...



Top 50 recent answers are included