New answers tagged

0

If you're fine with compromising the security a little, change the sudoers rule such that it doesn't prompt for password.


2

The way to do it is: sudo bash -i -c 'tailc -f -n 10 /var/log/syslog' But that syntax is ugly, so I went in a different direction. I created a script /usr/local/bin/tailc with permission 755: #!/bin/bash tail $@ | ccze Now I can use tailc / sudo tailc as I wanted.


0

$ type kill kill is a shell builtin Running just kill -l runs the shell's builtin version of it. But sudo doesn't run its commands through a shell, so sudo kill -l runs /bin/kill found through $PATH instead. Two different implementations of essentially the same utility, and they just have a slightly different output format for -l. You could get a similar ...


1

You can do this with sudo (editing the sudoers file, as you suspected) but really shouldn't. I'm pretty sure useradd -o -u 0 whatever will happily add you a new root account. Similarly, usermod -o -u 0 whatever will happily make an existing account into a root account. usermod can also change an account's shell (change the sysadmin's shell). Various groups ...


0

Solved thanks to @MarkPlotnick! the logger command does what I need, no need for chmod or anything like that. alias Insys='logger =================== Setting chat and Options for Insys ; cp /var/config/tw_con_Insys.lge /var/config/tw_con.lge; cp /etc/ppp/peers/tw_options_Insys /etc/ppp/peers/tw_options; con; logger =================== Complete; ...


1

You are using a wrapper, not a pipe. Wrappers will carry their permissions with them. In this instance for purely security reasons, please use sudo watch dmesg instead of watch sudo dmesg so that you trigger the sudo authentication only once. Otherwise it will continually refresh your authentication as sudo runs every second. If you then step away and ...


1

Interesting, order does matter in PAM. It works if pam_unix come before pam_sss: auth sufficient pam_unix.so try_first_pass nullok auth sufficient pam_sss.so use_first_pass password sufficient pam_unix.so try_first_pass use_authtok nullok sha512 shadow password sufficient pam_sss.so use_authtok


0

Add this to /etc/sudoers, replacing <username> with your username: <username> ALL = NOPASSWD: /usr/bin/brightlight


0

I recently experienced this problem because I ran the following command sudo chmod -R 777 /usr/* Unfortunately /usr/bin/sudo is not owned by root and breaks as a result. To fix the problem I booted into recovery mode which provides a scroll down menu with an option to drop down to a root shell. From the root shell I ran the following commands: mount -o ...


-1

1.You can check whether you are a part of sudo group or not by using below command groups username ===> it will lists the groups for which he belongs too We can check by below script too h=`groups username| awk -F ":" '{print $2}'| grep -io 'sudo'` if [[ $h == "sudo" ]] then echo "user praveen is part of group sudo" else echo "Need to add user to group ...


1

From man useradd (8): -p, --password PASSWORD      The encrypted password, as returned by crypt(3). The default is to disable the password. Look into /etc/shadow and you will see that the encrypted password is 12345. So it's no wonder that your password is wrong. You can change the password as root with passwd tom and it ...


1

Using: echo $(tput setaf <colour>)<text>$(tput sgr0) >> /etc/sudoers.lecture adds coloured text to /etc/sudoers.lecture


2

The easiest method I've found to accomplish this is to SSH to a server which will be picking up the sudo rule and check a user in the group that's being granted this type of access. You can use the sudo commands -l and -U switches: $ man sudo -l, --list If no command is specified, list the allowed (and forbidden) commands for the invoking ...


1

I suspect you meant to ask specifically about chmod o+x, to enable other (i.e. someone who is neither the user nor a member of the specified group) users to execute the file. chmod a+x is a superset of chmod o+x since it turns on the execute permission for all 3 (user, group, and other). The difference then is the context in which the program will run. With ...


0

A rather large difference is the fact that if you run a program directly, it runs with the rights of your user id, but with sudo, you're using somebody else's user id and their rights: Consider your usual system where /bin/ls is executable by anyone, and /root is readable only by the root user itself: $ /bin/ls /root/test /bin/ls: cannot access '/root/test'...


Top 50 recent answers are included