Adding an entry in /etc/sudoers

Latest response

This should be pretty straight forward, but I haven't messed with the /etc/sudoers in some time and can't quite seem to get my syntax correct.

I have created a vendor account that needs to be able to sudo to a service account.

I started with some user alias configs, but here is where I am now.

vendor ALL=(service) NOPASSWD: /bin/su

Sorry, user vendor is not allowed to execute '/bin/su - service' as root on

Been awhile and don't do a lot with this. Probably something obvious, that I am just not seeing.

Thanks

JJ
Log in to join the conversation

Responses

Dusan Baljevic's picture Pro 469 points
26 February 2018 9:10 PM

Hi John,

Unless I misunderstood you, here is what you want, in simplest terms

vendor ALL=(ALL) NOPASSWD: /bin/su -l service

Regards,

Dusan Baljevic (amateur radio VK2COT)

Thomas Jones's picture Guru Community Member 3711 points
26 February 2018 9:46 PM

Bear in mind that, with typical "service" accounts (e.g., the apache user's account), the account is set up without a valid interactive shell (something like /sbin/nologin, /bin/true, etc.). This means that you're not going to be able to just su in without telling the command what shell to use.

To get to such an account, you'd typically use an invocation like su -s /bin/bash - <SERVICE_ACCOUNT>. Thus, your sudoers entry would look something like:

vendor ALL=(ALL) NOPASSWD: /bin/su -s /bin/bash - apache

If you don't use the -s /shell/path type notation for accounts that have no defined interactive shell, you'll get an error saying This account is currently not available.

R. Hinton.'s picture Guru 10133 points
26 February 2018 11:27 PM

Hi John,

Dusan Baljevic and Thomas Jones' gave some great info and their examples will certainly work, and I just wanted to give you some more info...

You may have heard of "man pages" (others will likely read this), which stands for "manual page" and in this very specific case... one of the absolutely very best "man pages" is the sudoers man page which is CHOCK FULL of example after example after example! Whoever wrote the manual page (joint effort apparently, according to the credits near the end) put considerable time, effort to add some of the very best examples of man pages ... known to man

Go to a Linux prompt and type:

man sudoers

Then enter a "/" once you are "in the man page" which will allow you to search, and search for the term "EXAMPLES" (in caps, and without the quotes). (or search for (no kidding) "fred" because there's plenty examples right within that area in the man page)

You can do a one-liner entry such as what Thomas Jones posted earlier, but you can set up 4 aliases, User_Alias, Runas_Alias, Host_Alias and Cmnd_Alias, which allows you to create something like "variables" if you intend to have "one sudoers file to rule them all".

If you need a sudoers directive on just one system then probably use Thomas Jones' example above, if you need consistency and to have a standardized set of sudoers directives for a a number of systems then consider the aliases and see the extensive amount of examples literally in the man page.

Yeah, correct, this post does say "read the man page" but in this case the man page for sudoers really does provide an excessive wonderful wealth of practical examples to learn from and to use.

Wish you well,

-RJ

R. Hinton.'s picture Guru 10133 points
26 February 2018 11:42 PM

Some examples:

Yes, this is more than you probably bargained for, but this explains the use of the aliases. some simpler examples follow this block below

 # User alias specification
       User_Alias     FULLTIMERS = millert, mikef, dowdy
       User_Alias     PARTTIMERS = bostley, jwfox, crawl
       User_Alias     WEBMASTERS = will, wendy, wim

       # Runas alias specification
       Runas_Alias    OP = root, operator
       Runas_Alias    DB = oracle, sybase
       Runas_Alias    ADMINGRP = adm, oper

       # Host alias specification
       Host_Alias     SPARC = bigtime, eclipse, moet, anchor :\
                 SGI = grolsch, dandelion, black :\
                 ALPHA = widget, thalamus, foobar :\
                 HPPA = boa, nag, python
       Host_Alias     CUNETS = 128.138.0.0/255.255.0.0
       Host_Alias     CSNETS = 128.138.243.0, 128.138.204.0/24, 128.138.242.0
       Host_Alias     SERVERS = master, mail, www, ns
       Host_Alias     CDROM = orion, perseus, hercules

       # Cmnd alias specification
       Cmnd_Alias     DUMPS = /usr/bin/mt, /usr/sbin/dump, /usr/sbin/rdump,\
                      /usr/sbin/restore, /usr/sbin/rrestore,\
                      sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ== \
                      /home/operator/bin/start_backups
       Cmnd_Alias     KILL = /usr/bin/kill
       Cmnd_Alias     PRINTING = /usr/sbin/lpc, /usr/bin/lprm
       Cmnd_Alias     SHUTDOWN = /usr/sbin/shutdown
       Cmnd_Alias     HALT = /usr/sbin/halt
       Cmnd_Alias     REBOOT = /usr/sbin/reboot
       Cmnd_Alias     SHELLS = /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh,\
                       /usr/local/bin/tcsh, /usr/bin/rsh,\
                       /usr/local/bin/zsh
       Cmnd_Alias     SU = /usr/bin/su
       Cmnd_Alias     PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less
Here's some great examples The description follows the example in the block 
       +secretaries   ALL = PRINTING, /usr/bin/adduser, /usr/bin/rmuser

Users in the secretaries netgroup need to help manage the printers as well as add and remove users, so they are allowed to run those commands on all machines.

       fred      ALL = (DB) NOPASSWD: ALL

The user fred can run commands as any user in the DB Runas_Alias (oracle or sybase) without giving a password.

       john      ALPHA = /usr/bin/su [!-]*, !/usr/bin/su *root*

On the ALPHA machines, user john may su to anyone except root but he is not allowed to specify any options to the su(1) command.

       jen       ALL, !SERVERS = ALL

The user jen may run any command on any machine except for those in the SERVERS Host_Alias (master, mail, www and ns).

       jill      SERVERS = /usr/bin/, !SU, !SHELLS

For any machine in the SERVERS Host_Alias, jill may run any commands in the directory /usr/bin/ except for those commands belonging to the SU and SHELLS Cmnd_Aliases. While not specifically mentioned in the rule, the commands in the PAGERS Cmnd_Alias all reside in /usr/bin and have the noexec option set.

R. Hinton.'s picture Guru 10133 points
26 February 2018 11:52 PM

one last example, I often have used active directory groups for one customer who has their Linux infrastructure using ldap/sssd - you can cite groups using a %those_development_users and then define a specific set of rules for that group, and maybe some of the development users have some admin rights, you can make a group and set of rules and cite a group you've made with %those_development_almost_admins (not trying to knock the dev folks), and this really helps if you have dozens of development systems and you don't want to panic edit 40 or more sudoers files with the ebb and flow of people that come and go from your project. Just a thought

-RJ

JJ Active Contributor 111 points
27 February 2018 2:07 PM

The very first place I looked were the man pages. And I tried a number of things found there, but it didn't give me what I was wanting or didn't work the way I needed. Then I took the Google route. The problem wasn't that I couldn't find any sudoers info, it was that there was so much. I was looking for a nuanced response, which led me here.

I did get something working, but it isn't my long term solution...that is going to take some more research I believe.

Thanks, John

R. Hinton.'s picture Guru 10133 points
27 February 2018 10:08 PM

Hi John,

Sorry, I just didn't know from your first post you hadn't tried the man pages, however, I'm hoping one of the posts earlier helped you.

Did the posts others made help? If not, tell us what you're interested in regarding a sudoers entry and one of us ought to chime in and provide an example that hopefully will scratch the itch of the need you have. It seems from the last entry you have something working. If you need additional help here, Just let us know,

Regards,

RJ

JJ Active Contributor 111 points
27 February 2018 10:25 PM

Thanks for the help....

Ultimately, what I want are to create are entries in /etc/sudoers that give members of specific groups the permissions I have preconfigured in the sudoers file. (i.e. local group "dba" is configured in /etc/sudoers that members of that group can sudo to the oracle service account.)

I haven't worked with a sudoers file in sometime, where I was previously went to a "become" model with very restricted /etc/sudoers access. We had a very large local linux user base, whereas where I am now almost no one need direct login access.

R. Hinton.'s picture Guru 10133 points
27 February 2018 10:54 PM

Hi John,

If you happen to be using LDAP or SSSD, with visibility to windows groups or (shudder) NIS, or some locally defined group, you could assign groups within those methods, then cite the group within your sudoers directives.

It seems you might be leaning to local groups existing on individual systems? You can set the group within /etc/groups and then in the /etc/sudoers file assign what you wish in a like (but not one-for-one) manner you see for the %wheel group entry.

The benefit fo this? you can adjust the group within /etc/group and not have to edit sudoers as much. That being said, an edit would still be an edit.

Would you ever be using IDM for authentication? I don't know if your groups could be from an external source such as active directory, (through ldap/sssd), or IDM (which is a form of LDAP plus a lot of other great features). If you did, you could cite the group from what your system could "see" and then not have to go to individual systems with the ebb & flow of people that come and go. However this might be moot for you and perhaps the changes you make may not be enough in volume to warrant that.

Anyway, if you have the "dba" (or whatever group(s)) you wish defined in /etc/sudoers, that will certainly work, you also have the option of citing groups for rules within /etc/sudoers for groups your "system can see" external (such as what I mentioned as active directory/ldap/sssd).

Let us know if we can help

-RJ

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.