visudo with Emacs

visudo with Emacs

[MON KEY]

Using visudo with $EDITOR set to emacs when saving /etc/sudoers
I'm left with /etc/sudoers.tmp~ in /etc with permissions as rw, i.e:

root> ls -ldZ /etc/sudoers
 -r--r-----. root root unconfined_u:object_r:etc_t:s0 /etc/sudoers

root> ls -ldZ /etc/sudoers.tmp~
 -rw-------. root root unconfined_u:object_r:etc_t:s0 /etc/sudoers.tmp~

When $EDITOR is not set visudo falls back to using the nonsensical
editor (i.e. /bin/vi). However, unlike Emacs, that editor does not
leave behind an /etc/sudoers.tmp~

AFAICT the stray /etc/sudoers.tmp~ is not in keeping with the
spirit of visudo. Emacs should operate equivalently with vi.

I'm able to remedy this by modifying /root/.bashrc and /root/.emacs to
contain the following:

,---- in /root/.emacs
| (when (member "_=/usr/sbin/visudo" process-environment)
|       (add-hook 'find-file-hook 'visudo-sudoers-p))
|
| (defun visudo-sudoers-p ()
|   (setq backup-enable-predicate 'visudo-no-tmp~)
|   (add-hook 'after-save-hook  'kill-sudoers.tmp~)))
|
|  (defun kill-sudoers.tmp~ ()
|    (when (file-exists-p "/etc/sudoers.tmp~")
|      (delete-file "/etc/sudoers.tmp~")))
|
| (defun visudo-no-tmp~  (maybe-sudoers.tmp)
|   (if (string= maybe-sudoers.tmp "/etc/sudoers.tmp")
|       (with-current-buffer (get-buffer-create "sudoers.tmp")
|         (setq backup-inhibited t)
|         (auto-save-mode -1)
|         nil)
|     t))
`----

,---- /root/.bashrc
| export EMACS="emacs --no-window-system --no-site-file --no-init-file
|               -u root -fg white -bg red"
| export EDITOR="$EMACS"
| export VISUAL="$EMACS"
`----

The above exports are bash centric and should really prob. run with an
Emacs built specifically without X support, instead we just pass the
--no-window-system and assume invocation from something resembling a
terminal.

The fg/bg params are mostly so we _know_ we're in a root'd Emacs.
The --no-init-file is to prevent picking up the init file from the
environment of an su'd user.

I would think something like the elisp above should be included with
Emacs if only to save users the agony of having to use vi :P

I've tested the above configurations from a tty and a gdm'd X session
with an Emacs built from distribution sources and the following build
specs:

GNU Emacs 23.3.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4) of 2011-06-15

Windowing system distributor `Fedora Project', version 11.0.11001000
configured using `configure ''--without-xft' '--with-x-toolkit=gtk'
'--with-dbus' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg'
'--with-tiff' '--with-xpm' '--without-sound''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

--
/s_P\

Re: visudo with Emacs

[Eli Zaretskii]

> Date: Sat, 18 Jun 2011 17:48:27 -0400
> From: MON KEY <monkey@sandpframing.com>
> 
> When $EDITOR is not set visudo falls back to using the nonsensical
> editor (i.e. /bin/vi). However, unlike Emacs, that editor does not
> leave behind an /etc/sudoers.tmp~
> 
> AFAICT the stray /etc/sudoers.tmp~ is not in keeping with the
> spirit of visudo. Emacs should operate equivalently with vi.

??? Why? what's wrong with leaving backup files in these use cases?
If nothing else, you get for free the ability to easily restore the
original files, if you happen to screw up.

Re: visudo with Emacs

[MON KEY]

On Sat, Jun 18, 2011 at 10:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> AFAICT the stray /etc/sudoers.tmp~ is not in keeping with the
>> spirit of visudo. Emacs should operate equivalently with vi.
>
> ??? Why? what's wrong with leaving backup files in these use cases?

AIUI visudo is an abstraction of an "atomic commit".

 - When invoked visudo visits /etc/sudoers.tmp
 - Edits are made.
 - When the file is saved (read committed) it is verified for
   correctness.
 - If the the commit is successful, visudo writes to /etc/sudoers and
   /etc/sudoers.tmp is removed.

My impression is that neither /etc/sudoers.tmp nor the backup file
/etc/sudoers.tmp~ are meant to be retained.

,---- (man "visudo")
| visudo locks the sudoers file against multiple simultaneous edits,
| provides basic sanity checks, and checks for parse errors.
|
| (...)
|
| visudo parses the sudoers file after the edit and will not save the
| changes if there is a syntax error.
|
| (...)
|
| FILES
|         /etc/sudoers           List of who can run what
|         /etc/sudoers.tmp       Lock file for visudo
 `----

> If nothing else, you get for free the ability to easily restore the
> original files, if you happen to screw up.

Restoring from /etc/sudoers.tmp~ would amount to restoring from the
lock file not /etc/sudoers !

The state represented by /etc/sudoers.tmp might be representative of a
failed commit...

Note, at best I'm an occasional user of sudo/visudo.

It would be nice if a sudo/visudo-devel or well versed sys-admin
familiar with the intricacies of visudo could comment on the
efficacy of Emacs' retention of /etc/sudoers.tmp~

--
/s_P\

Re: visudo with Emacs

[Sven Joachim]

On 2011-06-19 22:46 +0200, MON KEY wrote:

> On Sat, Jun 18, 2011 at 10:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> AFAICT the stray /etc/sudoers.tmp~ is not in keeping with the
>>> spirit of visudo. Emacs should operate equivalently with vi.
>>
>> ??? Why? what's wrong with leaving backup files in these use cases?
>
> AIUI visudo is an abstraction of an "atomic commit".
>
>  - When invoked visudo visits /etc/sudoers.tmp
>  - Edits are made.
>  - When the file is saved (read committed) it is verified for
>    correctness.
>  - If the the commit is successful, visudo writes to /etc/sudoers and
>    /etc/sudoers.tmp is removed.

More exactly, visudo renames /etc/sudoers.tmp to /etc/sudoers so that
the commit is indeed atomic.

> My impression is that neither /etc/sudoers.tmp nor the backup file
> /etc/sudoers.tmp~ are meant to be retained.

Since it serves as a lockfile, /etc/sudoers.tmp must not be retained
(visudo either renames or unlinks it, depending on whether you have made
changes or not), but /etc/sudoers.tmp~ does no harm.

>> If nothing else, you get for free the ability to easily restore the
>> original files, if you happen to screw up.
>
> Restoring from /etc/sudoers.tmp~ would amount to restoring from the
> lock file not /etc/sudoers !

And?  /etc/sudoers.tmp~ is still a backup file of /etc/sudoers and so
might be useful.

Cheers,
       Sven

Re: visudo with Emacs

[MON KEY]

On Sun, Jun 19, 2011 at 5:25 PM, Sven Joachim <svenjoac@gmx.de> wrote:
>
> More exactly, visudo renames /etc/sudoers.tmp to /etc/sudoers so that
> the commit is indeed atomic.

Thank you for clarifying with specificity
(it wasn't IMO entirely clear from man visudo).

>
>> My impression is that neither /etc/sudoers.tmp nor the backup file
>> /etc/sudoers.tmp~ are meant to be retained.
>
> Since it serves as a lockfile, /etc/sudoers.tmp must not be retained
> (visudo either renames or unlinks it, depending on whether you have made
> changes or not), but /etc/sudoers.tmp~ does no harm.

I'm sure you're right.

Still, it seems there may be corner cases where the backup might not
be entirely sanitary.  I'm still curious though about what happens to
the inode (and corresponding metadata) around /etc/sudoers.tmp~ e.g.:

root> ls -ldZ /etc/sudoers.tmp~
 -rw-------. root root unconfined_u:object_r:etc_t:s0 /etc/sudoers.tmp~

>> Restoring from /etc/sudoers.tmp~ would amount to restoring from the
>> lock file not /etc/sudoers !
>
> And?  /etc/sudoers.tmp~ is still a backup file of /etc/sudoers and so
> might be useful.

How can it be both?
Either its a backup of /etc/sudoers or of /etc/sudoers.tmp~

Depending on the underlying linking it might _be_ useful albeit maybe
in unintended ways...

> Cheers,
>       Sven

--
/s_P\

Re: visudo with Emacs

[Sven Joachim]

On 2011-06-20 07:55 +0200, MON KEY wrote:

> Still, it seems there may be corner cases where the backup might not
> be entirely sanitary.  I'm still curious though about what happens to
> the inode (and corresponding metadata) around /etc/sudoers.tmp~ e.g.:
>
> root> ls -ldZ /etc/sudoers.tmp~
>  -rw-------. root root unconfined_u:object_r:etc_t:s0 /etc/sudoers.tmp~

The permissions are not what sudo expects (unless you have configured it
--with-sudoers-mode 600), and security context can only be preserved if
both visudo and Emacs support selinux.

>>> Restoring from /etc/sudoers.tmp~ would amount to restoring from the
>>> lock file not /etc/sudoers !

The recommended way to restore is to run visudo again and restore
sudoers.tmp within the editor.  Otherwise you risk shooting yourself in
the foot, like you do when editing /etc/sudoers directly.

Cheers,
       Sven