Strange sudoers problem.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange sudoers problem.

Wynona Stacy Lockwood
I have an odd problem with sudoers. Recently, I've tried to make use of /etc/sudoers.d/ rather than editing /etc/sudoers itself. This, in theory, should ensure that future upgrades to sudo will not munge my additions by leaving the stock /etc/sudoers intact. Research has lead me to believe that files in /etc/sudoers.d/ need to be dot files (I.E. a "hidden" file) and need to be mode 0440. I have done both of these things, however, the groups I define for sudo access in my /etc/sudoers.d/.devops.sudoers file are not processed, even after a reboot. Anyone else have this problem?

--
Wynona Stacy Lockwood
[hidden email]


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange sudoers problem.

Robert Heller
At Mon, 2 Jul 2018 14:09:56 -0500 "Ubuntu user technical support,  not for general discussions" <[hidden email]> wrote:

>
>
>
> I have an odd problem with sudoers. Recently, I've tried to make use of
> /etc/sudoers.d/ rather than editing /etc/sudoers itself. This, in theory,
> should ensure that future upgrades to sudo will not munge my additions by
> leaving the stock /etc/sudoers intact. Research has lead me to believe that
> files in /etc/sudoers.d/ need to be dot files (I.E. a "hidden" file) and
> need to be mode 0440. I have done both of these things, however, the groups
> I define for sudo access in my /etc/sudoers.d/.devops.sudoers file are not
> processed, even after a reboot. Anyone else have this problem?

Hidden? Nope. "Hidden" only make sense in $HOME (and other places that *users*
will be commonly running ls, like code trees [think .git or .svn]), as a
kludge to "hide" them and avoid a long/cluttered file listings. According to
the README in that directory, the filenames must NOT *contain* a period (not
sure why) or end in ~ (eg editor backup files [Duh]).

Mode 0440, yes.  And yes, anything you drop in /etc/sudoers.d/ won't be
touched by updates.  And there needs to be at least one file in that directory
(the README file will do).

>

--
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
[hidden email]       -- Webhosting Services
                                 

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange sudoers problem.

Wynona Stacy Lockwood
On Mon, Jul 2, 2018 at 2:31 PM, Robert Heller <[hidden email]> wrote:
At Mon, 2 Jul 2018 14:09:56 -0500 "Ubuntu user technical support,  not for general discussions" <[hidden email]> wrote:

> I have an odd problem with sudoers. Recently, I've tried to make use of
> /etc/sudoers.d/ rather than editing /etc/sudoers itself. This, in theory,
> should ensure that future upgrades to sudo will not munge my additions by
> leaving the stock /etc/sudoers intact. Research has lead me to believe that
> files in /etc/sudoers.d/ need to be dot files (I.E. a "hidden" file) and
> need to be mode 0440. I have done both of these things, however, the groups
> I define for sudo access in my /etc/sudoers.d/.devops.sudoers file are not
> processed, even after a reboot. Anyone else have this problem?

Hidden? Nope. "Hidden" only make sense in $HOME (and other places that *users*
will be commonly running ls, like code trees [think .git or .svn]), as a
kludge to "hide" them and avoid a long/cluttered file listings. According to
the README in that directory, the filenames must NOT *contain* a period (not
sure why) or end in ~ (eg editor backup files [Duh]).

Mode 0440, yes.  And yes, anything you drop in /etc/sudoers.d/ won't be
touched by updates.  And there needs to be at least one file in that directory
(the README file will do).
 

Thank you! I'll try that.

-- 
Wynona Stacy Lockwood
[hidden email]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange sudoers problem.

Colin Watson
In reply to this post by Robert Heller
On Mon, Jul 02, 2018 at 03:31:43PM -0400, Robert Heller wrote:
> According to the README in that directory, the filenames must NOT
> *contain* a period (not sure why)

I expect it's a simple way to exclude things like *.dpkg-* created by
packaging systems, and indeed some editor backup files that don't end in
'~'.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange sudoers problem.

Tom H-4
In reply to this post by Wynona Stacy Lockwood
On Mon, Jul 2, 2018 at 8:11 PM Wynona Stacy Lockwood <[hidden email]> wrote:

>
> I have an odd problem with sudoers. Recently, I've tried to make use
> of /etc/sudoers.d/ rather than editing /etc/sudoers itself. This, in
> theory, should ensure that future upgrades to sudo will not munge my
> additions by leaving the stock /etc/sudoers intact. Research has lead
> me to believe that files in /etc/sudoers.d/ need to be dot files (I.E.
> a "hidden" file) and need to be mode 0440. I have done both of these
> things, however, the groups I define for sudo access in my
> /etc/sudoers.d/.devops.sudoers file are not processed, even after a
> reboot. Anyone else have this problem?

"/etc/sudoers.d/" files don't need to be dot-files. In fact, I doubt
that dot-files are read. AFAIK, files including a dot aren't read; I
assume that this includes a file that starts with a dot.

It's best to use "visudo -f /etc/sudoers.d/<file>". Either $VISUAL or
$EDITOR will be used, if set; otherwise vi'll be used.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange sudoers problem.

Ralf Mardorf-2
On Sun, 8 Jul 2018 15:13:17 +0100, Tom H wrote:

>On Mon, Jul 2, 2018 at 8:11 PM Wynona Stacy Lockwood wrote:
>> I have an odd problem with sudoers. Recently, I've tried to make use
>> of /etc/sudoers.d/ rather than editing /etc/sudoers itself. This, in
>> theory, should ensure that future upgrades to sudo will not munge my
>> additions by leaving the stock /etc/sudoers intact. Research has lead
>> me to believe that files in /etc/sudoers.d/ need to be dot files
>> (I.E. a "hidden" file) and need to be mode 0440. I have done both of
>> these things, however, the groups I define for sudo access in my
>> /etc/sudoers.d/.devops.sudoers file are not processed, even after a
>> reboot. Anyone else have this problem?  
>
>"/etc/sudoers.d/" files don't need to be dot-files. In fact, I doubt
>that dot-files are read. AFAIK, files including a dot aren't read; I
>assume that this includes a file that starts with a dot.
>
>It's best to use "visudo -f /etc/sudoers.d/<file>". Either $VISUAL or
>$EDITOR will be used, if set; otherwise vi'll be used.

If a global config file installed by a package was edited, dpkg does
notice this, by using a checksum of the last installed config file that
was installed by the package. Conifgs in $HOME are always kept
untouched. An edited config file will not be replaced by new config
file, by default dpkg instead ask the administrator what to do.
It's possible to change the default behaviour by the --force-confnew or
--force-confold option.

Btw. mode 0440 isn't a smart way to make a file immutable, instead it
the OP should consider to make it really immutable, by using

  sudo chattr -i /path/file

Regarding the used editor I wouldn't export it globally, instead I
usually add

  export EDITOR="nano"

to

  $HOME/.bashrc


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users