New answers tagged

10

Looks like you missed something. From the Debian documentation: 6.3.2. Setting Up Users And Passwords Just before configuring the clock, the installer will allow you to set up the “root” account and/or an account for the first user. Other user accounts can be created after the installation has been completed. 6.3.2.1. Set the Root Password ...


1

If you allow running almost any binary in the system binary directories, with arbitrary arguments, you almost certainly have allowed arbitrary access. Among other things, if you allow running an editor with arbitrary arguments, or mv, or a shell like bash, or a package manager like dpkg, or any program that supports writing data to files, then someone could ...


0

The other answer covers the hassle, I just want to point out that securing the sudoers file contents needs to also be consider what the checksums will not protect against... Lets say you have the following in the sudoers file and you only want low priv users to use the apache binary (I have not provided a sha-2 checksum example as it will complicate the ...


2

You have pam_google_authenticator.so enabled in /etc/pam.d/common-auth. common-auth is included in (almost) every other file in /etc/pam.d/ - that's its purpose, to provide common authentication rules for programs that use pam. If you don't want every program to use google 2-factor auth, delete it from /etc/pam.d/common-auth.


0

Physical security is security. You have three options: Log in as root, either from the console or by ssh. Boot in single-user mode, which traditionally doesn't need the root password (but might on your system). Mount the disk image from another OS. Any of these will give you the ability to change the ownership of any file on the disk. If none of ...


2

The problem is probably that su - will clear all the environment variables except TERM, so you will lose the DISPLAY setting. Try setting DISPLAY=localhost:10.0 (for example) before the gedit.


3

Sounds like a huge pain to me. I don't think you're actually gaining anything in security, either, as those (a) can only be written as root, so already likely game over if someone can write to them; (b) likely load a bunch of shared libraries, which aren't being checked. The sudoers manpage says the option "may be useful in situations where the user ...


-1

Repos: Active apt sources in file: /etc/apt/sources.list deb http://packages.linuxmint.com/ debian main upstream import deb ht tp :// debian.linuxmint.com/latest testing main contrib non-free deb ht tp:// debian.linuxmint.com/latest/security testing/updates main contrib non-free deb h ttp:// ...


1

You say "I AM able to sudo.... but not sys updates for some reason". But the transcript you posted shows that you cannot, as sudo nano fails with not in sudoers. To fix, check which group(s) you're in: groups timothy. Then grep /etc/sudoers for either timothy or any of the groups that showed up. I'm pretty sure you'll find out none of them do. Then check ...


1

sudo adduser timothy creates a user called timothy. It doesn't create a sudo user called timothy. To give timothy some sudo privileges you need to edit the sudoers file, e.g. add this entry to permit timothy to run any command as root, without re-entering his password. timothy ALL=(ALL) NOPASSWD: ALL


4

sudo is not saying the user doesn't exist, just that it is not in the sudoers file. adduser is a script to add a system user, not an entry in the sudoers file. To do what you want, you need to grant rights to timothy with visudo. Check man sudoers for details.


0

I did not figure out how to make sudo use the correct default audio device but I did find a work around for my case. By using sudo -u someUserName python3 soundtest.py I was able to run the python script from the profile it was working for.


0

For me worked fine like this, but with notice about: Pseudo-terminal will not be allocated because stdin is not a terminal ssh -t username@hostname1 << 'EOS' sudo sh hostname EOS Pseudo-terminal will not be allocated because stdin is not a terminal. hostname1


0

If you grant a user access to login to an account, you grant full access to that account and any means you try to detect the difference can easily be overcome with basic environment manipulations. If you wish to block the login and ssh, you could add instructions in your /etc/sudoers file such as: UserName ALL = !/bin/bash UserName ALL = !/bin/sh ...


2

I suppose in that case nano is using another .nanorc? Yep. When you run sudo nano file, HOME environment variable is set to /root, so nano looks for .nanorc there. Just add the setting into /root/.nanorc, and you should be fine.


-2

Just: # echo "<newuser> ALL=(ALL) ALL" >> /etc/sudoers Cf: https://www.debian.org/doc/manuals/debian-reference/ch01.en.html#_sudo_configuration And personnaly I would use: # tee -a "<newuser> ALL=(ALL) ALL" >> /etc/sudoers tee -a present the advantage of merge stuff to the existant without removing the old stuff


3

From the sudoers man page User_List ::= User | User ',' User_List User ::= '!'* user name | '!'* #uid | '!'* %group | '!'* %#gid | '!'* +netgroup | '!'* %:nonunix_group | '!'* %:#nonunix_gid | '!'* User_Alias simply use (the confusingly named group): %stupiduser HOSTS_HERE = ...


3

You do not need to reboot, but you do need to log out and back in which a reboot forces you to do. Your group membership isn't dynamically updated, so if you add yourself to the sudo group you won't be a member of the group until the next time you log in.


13

In some sense this message is already customisable because, as for many parts of GNU/Linux, sudo is internationalised and uses gettext Native Language Support to look up most strings to replace them by a locale version in a different language. For example, you can see the French language file here which has entries: msgid "%s is not in the sudoers file. ...


0

sudo allows regular users to run commands as root. Unless you provide an explicit list of very specific commands it is virtually impossible to prevent a user with sudo access from doing anything they like (and subsequently covering their tracks) with content that doesn't leave the server. Your question is usually triggered by people who don't really grasp ...


0

If this helps, you can use "NOEXEC" option of sudoers. You need to define it as USER_NAME ALL=(ALL) NOEXEC : ALL This will prevent shell escapes and user won't be able to use sudo -i or sudo -s or sudo su - This comes with a downside, however, Any shell escape will be disabled. for ex- executing script from within a script will also be denied. ...


2

Per man visudo, section "Diagnostics": /etc/sudoers.tmp: Permission denied You didn’t run visudo as root. I see nothing in your post to indicate that you did run it as root. Try sudo visudo. Also it looks like you may be getting errors related to sudo itself. Can you sudo ls ~root successfully? You may also want to review the man page, as: ...


5

You are missing the commas: tina,lu ALL = /bin/chmod, /bin/chown, /bin/chgrp Without the commas you are giving the right to execute /bin/chmod /bin/chown /bin/chgrp which of course doesn't make sense, but is syntactically valid as far as visudo knows.


1

tina needs to write sudo chgrp .... Otherwise, the the sudoers is not considered.


5

To see another users sudo permissions you can use: sudo -l -U <user>. Provided you have enough permissions yourself. Or (to answer the question) you can use the su command (aka switch-user). Running it as su - tina will switch to that user and run the login scripts (drop the - to skip this part). You will be prompted for their password. Or, you use ...


0

This is probably the result of cached authentication credentials being recycled in your sudo invocations. Try using sudo -k <some_allowed_command> and see if that gets you the behavior you expect.


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


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 ...


4

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.



Top 50 recent answers are included