I want to configure passwordless sudoedit, to edit files under /etc with the exception of sudoers files themselves. I tried using the following /etc/sudoers.d/sudoedit:

%sudo ALL=(root) NOPASSWD: sudoedit ^/etc/(?!sudo).*$

but that does not seem to work as sudo uses an old regex engine without the negative lookahead feature. Is there another way to achieve this? Maybe with the combination of /etc and the negation of !/etc/sudo?

I'm doing some scripting with Vim and I've just started using sudoedit. Problem is, when I :w it writes to the temp file, so any testing of the script can't happen unless I quit the editor. How can I force an update of the original, or am I missing the point of sudoedit?

We need to add few users to the sudoers file on Linux. They should be able to to anything root can except the following: * Should not modify, read, delete /nfsshare/config * Should not modify, read, delete /etc/passwd * Should not mount anything * Should not change root password * Should not edit /etc/sudoers or run visudo to add other users Is this possible?

I'm administrating an Arch Linux server. How can I securely add emacs to my /etc/sudoers editor variable? Currently I have "emacs" but that allows M-x shell. Basically, I want something like rvim, but for emacs.

Using

visudo

I add the line

ALL=(ALL) NOPASSWD: /home/user/script.sh

in

but the **script.sh** does not run on double click. If I add the line

ALL=(ALL) NOPASSWD:ALL

in

then the **script.sh** runs and works when double clicked. How can do it? Thanks.

Why can't I edit files owned by root but being e.g. somewhere deep in my personal directory, it says: > sudoedit: existingFile: editing files in a writable directory is not permitted While I have the following function defined:

function sunano {
    export SUDO_EDITOR='/usr/local/bin/nano'
    sudoedit "$@"
}

And I edit like this: sunano existingFile Where the file is indeed owned by root: ls -l existingFile Proves that: > -rwxr-xr-x 1 root root 40 Jun 15 2015 existingFile

I am looking for a solution to a use case where a group is granted sudoer privileges. However, only one specific user or member within that group should have sudoer permission privileges, while the remaining members of the group should not have permission to access sudoer privileges. In summary: A group has been granted sudoer privileges. Only one member of the group should have sudoer privileges. The rest of the group's members should not have sudoer privileges.

I am attempting to modify the sudoers files located within the sudoers.d directory to allow a group named "**swts**" to perform a cp and chown as part of an automation job. To accomplish this, I created a Cmnd_Alias as follows and saved in file called /etc/sudoers.d/00-cmds-swts: Cmnd_Alias SWTS_COMMANDS = /usr/bin/cp -r * /home/bbc/leo/BQD*, /bin/chown -R bbc:bbc /home/bbc/leo/BQD* However, when using visudo to edit the file and attempting to save, I receive the following error: >>> 00-cmds-qa: syntax error near line 1 <<< I am not sure what I am missing. Is it something with the source for the cp command? I finally utilized the command alias in another file under /etc/sudoers.conf/swts-users which has below contents: %swts ALL=(bbc:bbc) NOPASSWD: SWTS_COMMANDS

I execute a normal command to create a file and it tells me access is denied, after that I use Sudo the file I created belongs to the root user and not to the user I created whoami returns user1 ls -l to the file i created shows root root and not user1 user1 all the simple command permission denied i tried to configure sudoers but nothing change

Is there a key difference between sudo -e and sudo vim. I have set up the sudoers file so that vim is my default editor. Is there a key difference between the two? Plus, should I switch from vim to rvim? I tried it but I had some problems with my config file

My user (tom) is mapped to user_u user , user_r role and user_t domain via semanage

[tom@localhost ~]$ id -Z
user_u:user_r:user_t:s0
[tom@localhost ~]$

because I have made the "default" as "user_u"

[tom@localhos ~]$ sudo semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          user_u               s0                   *
root                 unconfined_u         s0-s0:c0.c1023       *
system_u             system_u             s0-s0:c0.c1023       *
[tom@localhos ~]$

but it still can perform sudo

[tom@localhost ~]$ sudo -l
Matching Defaults entries for tom on localhost:

User tom may run the following commands on localhost:
    (ALL) NOPASSWD: ALL
[tom@localhost ~]$

It seems, this is because of "% ALL = (ALL) NOPASSWD:ALL" in the sudoers

[tom@localhost ~]$ sudo cat /etc/sudoers
root ALL = (ALL) NOPASSWD:ALL
% ALL = (ALL) NOPASSWD:ALL
admin ALL = (ALL) NOPASSWD:ALL
[tom@localhost ~]$

Please help me fix my issue

System: Linux Mint 18.1 64-bit Cinnamon . ------------- Objective: To define Bash aliases to launch various CLI and GUI text editors while opening a file in root mode from gnome-terminal emulator. --------------------------------------------------------- Progress ----------- For example, the following aliases seem to work as expected: For CLI , in this example I used Nano (official website ): alias sunano='sudo nano' For GUI , in this example I used Xed (Wikipedia article ): alias suxed='sudo xed' They both open a file as root . --------------------------------------------------------- Problem ------------ I have an issue with gksudo in conjunction with sublime-text : alias susubl='gksudo /opt/sublime_text/sublime_text' ***Sometimes*** it works. It just does not do anything most of the time. How do I debug such a thing with inconsistent behavior? It does not output anything. No error message or similar. ------------------ Question ---------- gksudo has been deprecated in Debian and also no longer included in Ubuntu 18.04 Bionic, so let me re-formulate this question to a still valid one: How to properly edit system files (as root) in GUI (and CLI) in Linux? ***Properly*** in this context I define as ***safely*** in case, for instance, a power loss occurs during the file edit, another example could be lost SSH connection, etc.

I wish to keep certain environment variables when a certain command is run as a certain user under sudo. man sudoers seems to suggest that Defaults can do this, if I've read the paragraph copied below correctly (see highlighted part), but the syntax spec beneath it doesn't seem to match that (unless it's the Runas portion?) and I have found no examples. Is it possible? My current, failing attempt is: /etc/sudoers.d/certain:4:23: syntax error Defaults:certain-user!/certain-command.sh env_keep += "ENV_VAR1 ENV_VAR2" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I've tried variations of this (adding spaces, changing the command etc) but to no avail. The paragraph I mentioned: > Defaults > Certain configuration options may be changed from their default values at run-time via one or more Default_Entry lines. These may affect all users on any host, all users on a specific host, a specific user, a specific command, or ***commands being run as a specific user***. Note that per-command entries may not include command line arguments. If you need to specify arguments, define a Cmnd_Alias and reference that instead. Default_Type ::= 'Defaults' | 'Defaults' '@' Host_List | 'Defaults' ':' User_List | 'Defaults' '!' Cmnd_List | 'Defaults' '>' Runas_List Any help or insight would be much appreciated.

I have read this answer but don't know how to add the following line into my sudoers file. matthew ALL=(ALL) NOPASSWD: /usr/sbin/service fancontrol start I ran "**sudo visudo**", and a "**/etc/sudoers.tmp**" window popped up. Is "**/etc/sudoers.tmp**" the correct file into which the line should be added? If so, under which line should I add the lines? How can I save it? I cannot find a "Save" option there.

I aim to run "**sudo service fancontrol start**" without a password. GNU nano 2.9.3 /etc/sudoers.tmp # # This file MUST be edited with the 'visudo' command as root.

I am using Kubuntu 20.04. When I run sudoedit /etc/fstab, VS Code opens to a blank document and the CLI immediately returns (see details below). If I run export SUDO_EDITOR=nano, the document opens in the nano editor with the contents of /etc/fstab as expected. If I run export SUDO_EDITOR=/snap/bin/code, it once again opens VS Code with a blank document. What am I doing wrong? Or is this a bug? *** kevin@kevcoder00 ~ $ echo $VISUAL kevin@kevcoder00 ~ $ echo $SUDO_EDITOR kevin@kevcoder00 ~ $ echo $EDITOR /snap/bin/code kevin@kevcoder00 ~ $ sudoedit /etc/fstab [sudo] password for kevin: sudoedit: /etc/fstab unchanged

Could you please help with below command. I need run without password prompt, But it requires password for user:

Cmnd_Alias user_RPM_YUM = /bin/rpm --allmatches -e $(rpm -qa blabla*) --nodeps
USER_USER DBS=(root) NOPASSWD: CODEDEPLOY_RPM_YUM

we create the following script on rhel 7.6 /home/run_tasks and in visudo we configured %sudo ALL=(ALL:ALL) ALL root ALL=(ALL) ALL hdfs ALL = (ALL) ALL hdfs ALL= (root) NOPASSWD: /home/run_tasks and ls -ltr /home/run_tasks -rwxrwxrwx 1 hdfs hdfs 6377 Sep 11 2019 /home/run_tasks so when we run the script as su hdfs -c "sudo /home/run_tasks" we get sudo: sorry, you must have a tty to run sudo and after we marked the following lines ( from visudo ) #Defaults requiretty #Defaults !visiblepw we get su hdfs -c "sudo /home/run_tasks" ls: Permission denied: user=root, access=EXECUTE, inode="/../../..":hdfs:hdfs:drwxr-x--- ls: Permission denied: user=root, access=EXECUTE, inode="/../../..":hdfs:hdfs:drwxr-x---

I'm in Ubuntu 18.04LTS and I want to change the sudoers file to execute sudo shutdown -h now without the need of password (for my_username). The steps I take were: With my user my_username open terminal: sudo visudo The line I added: my_username ALL=(ALL) NOPASSWD: /sbin/shutdown Where there is only one tab in the first part (between user and ALL) and the rest are spaces. The user is the one it appears after id in terminal. After that, just in case I restart the system, and type sudo shutdown -h now but it keeps asking for password. What I'm doing wrong? -----EDIT------ Ok, I didn't know that the order in which you add the lines were important, so as asked I added my full file (it's a very simple sudoers config).

#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset
Defaults	mail_badpass
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
my_username	ALL=(ALL) NOPASSWD: /sbin/shutdown
#includedir /etc/sudoers.d

This way it works perfectly for me. The problem was that I added the line after root line.

sudoedit does not allow editing files when the original user has write access to one of the parent directories (as explained [here](https://unix.stackexchange.com/questions/356142/sudoedit-root-owned-file-in-a-non-root-directory/356145#356145)) . However, I'm noticing that sudoedit does not seem to take into account the sticky bit when performing this check. For example, I have /tmp with mode 1777 owned by root:root, and /tmp/foo also owned by root:root. Since /tmp has the sticky bit set, I think I should be able to use sudoedit on /tmp/foo, but I can't:

$ sudoedit /tmp/foo
sudoedit: /tmp/foo: editing files in a writable directory is not permitted

Shouldn't sudoedit be able to notice the sticky bit and not consider /tmp to be writable for the purposes of this check? Or would doing so introduce some security issue I'm not aware of?

Alright, I know the question title sucks, but it's the same with the situation itself. What I am trying to do is this: 1. Create a file with sudoers configuration locally 2. Use Ansible to ubload that file with the template module 3. Use the validate feature of the template module to make sure the configuration works So far, so good. Now comes the weird part: The validation (validate: 'visudo -cf %s') of that file throws an error. When I comment out the validation line the files gets uploaded, but a manual validation (visudo -cf /etc/sudoers.d/foo_bar) fails also. Opening the file using vi, saving it (:wq) without making any changes and running the validation again succeeds. My current working thesis: WTF?! But it's late and I am tired. If anyone has suggestions please let me know. I will update this question as soon as I have new information and I will clean it up once I zero in on a solution.