The pixie no longer needs to be setuid-root.
authorMark Wooding <mdw@distorted.org.uk>
Thu, 11 Apr 2013 11:02:21 +0000 (12:02 +0100)
committerMark Wooding <mdw@distorted.org.uk>
Thu, 11 Apr 2013 11:05:43 +0000 (12:05 +0100)
So turn off the option by default, and downgrade the question.  Also
make the documentation more useful and up-to-date.

debian/catacomb-bin.config
debian/catacomb-bin.templates
pixie.1

index 49d6dbf..16b4f3b 100644 (file)
@@ -1,5 +1,5 @@
 #! /bin/sh -e
 . /usr/share/debconf/confmodule
 db_version 2.0
 #! /bin/sh -e
 . /usr/share/debconf/confmodule
 db_version 2.0
-db_input medium catacomb-bin/pixie-is-setuid || true
+db_input low catacomb-bin/pixie-is-setuid || true
 db_go || true
 db_go || true
index d4fb741..66fd54f 100644 (file)
@@ -1,14 +1,16 @@
 Template: catacomb-bin/pixie-is-setuid
 Type: boolean
 Template: catacomb-bin/pixie-is-setuid
 Type: boolean
-Default: true
+Default: false
 Description: Install pixie setuid-root?
  Catacomb provides a `passphrase pixie' which prompts for passphrases
  (either on its terminal or using an external command) and remembers them
  for a configurable period of time.
  .
  For added security, the pixie can ensure that the memory it uses for
 Description: Install pixie setuid-root?
  Catacomb provides a `passphrase pixie' which prompts for passphrases
  (either on its terminal or using an external command) and remembers them
  for a configurable period of time.
  .
  For added security, the pixie can ensure that the memory it uses for
- passphrases is not swapped to disk.  To do this, it must be installed
- setuid root.  While the pixie has been carefully written so that this
- shouldn't be a security problem -- it allocates a small amount of memory,
- marks it as unswappable and then drops privileges immediately -- it may
- make some administrators nervous, so you have the option.
+ passphrases is not swapped to disk.  Nowadays this usually just works
+ assuming that users have a sensible RLIMIT_MEMLOCK setting.  Even so, it can
+ be installed setuid root just to make sure.  While the pixie has been
+ carefully written so that this shouldn't be a security problem -- it
+ allocates a small amount of memory, marks it as unswappable and then drops
+ privileges immediately -- it's not really recommended any more.  If in
+ doubt, say N here.
diff --git a/pixie.1 b/pixie.1
index c83b013..ced4b48 100644 (file)
--- a/pixie.1
+++ b/pixie.1
@@ -125,10 +125,13 @@ Send log messages to the syslog rather than stderr.
 .\"
 .SS "Memory management"
 During initialization, the pixie attempts to allocate a block of memory
 .\"
 .SS "Memory management"
 During initialization, the pixie attempts to allocate a block of memory
-from the kernel and protect it against being swapped to disk.  On most
-systems, this requires that the pixie start with root privileges,
-although it will drop them as soon as it can (before parsing
-command-line options).
+from the kernel and protect it against being swapped to disk.  On Linux
+and other systems with
+.B RLIMIT_MEMLOCK
+or similar, this should just work assuming that the limit is set
+sensibly.  On other systems, this requires that the pixie start with
+root privileges, although it will drop them as soon as it can (before
+parsing command-line options, for example).
 .PP
 The locked memory is used for all of the passphrases which the pixie
 stores, and for the buffers used to hold requests from clients.
 .PP
 The locked memory is used for all of the passphrases which the pixie
 stores, and for the buffers used to hold requests from clients.