Provided by: cryptmount_5.3.3-1_amd64 bug


       cmtab - static information about filesystems managed by cryptmount


       Information about the encrypted filesystems managed by cryptmount is contained in the file
       /etc/cryptmount/cmtab.  Each filesystem is labelled by a target name which can be used  as
       an argument to cryptmount and which appears in /etc/cryptmount/cmtab in front of a list of
       parameters describing where that filesystem is stored, and how it is encrypted.

       The format of the cmtab is flexible, with the description of each target  being  delimited
       by  braces,  parameters  being  specified by KEY=VALUE pairs, and white-space being freely
       usable.  Comments are prefixed by a '#' character, and can start at any point in  a  line,
       lasting  to  the  end  of the line.  The backslash character '\' can be used to ignore any
       special significance of the following character, for example  to  include  a  space  in  a

       /etc/cryptmount/cmtab contains entries of the following form:

           TARGET_NAME {
               dev=DEVICE                      # REQUIRED
               dir=MOUNT_POINT                 # REQUIRED
               fstype=TYPE                     # REQUIRED
               keyfile=KEYFILE                 # REQUIRED

       Some  fields, such as 'dev' and 'fstype' are mandatory, although many fields have sensible
       default values.  Depending  on  the  choice  of  KEYMANAGER,  fields  such  as  'keyhash',
       'keycipher', 'keymaxlen' may need to be set explicitly.

       Any  field  which  contains non-numerical values (e.g. not 'startsector', 'ivoffset' etc.)
       can contain references to environmental variables of  the  form  $(HOME).   The  following
       variables  are  recognized, all based on the characteristics of the user currently running
       cryptmount :
         * $(HOME) - the home directory, as obtained from /etc/passwd
         * $(UID) - the numerical identifier of the user
         * $(USERNAME) - the printable name of the user
         * $(GID) - the numerical identifier of the user's current group
         * $(GROUPNAME) - the printable name of the user's current group


       The components in each target definition have the following meaning:

       TARGET_NAME { ... }
              specifies the name that cryptmount uses to refer to a particular  filesystem,  with
              configuration  options  for  that  filesystem contained within the matching braces.
              The special name "_DEFAULTS_" may be used  to  set  default  values  in  subsequent
              targets for various parameters such as 'flags', 'fstype', 'mountoptions', 'cipher',
              'keyformat', 'keyhash', 'keycipher', 'keymaxlen', 'passwdretries'.   Note  that  if
              the  "_DEFAULTS_"  target  appears  more  than  once, each will undo the effects of
              previous default values - i.e. this pseudo-target does not operate incrementally.

       dev=DEVICE     (required)
              sets the  name  of  the  raw  device  (e.g.  /dev/hdb63)  or  ordinary  file  (e.g.
              /home/secretiveuser/private.fs)  that contains the encrypted filesystem.  Note that
              it may be useful to use a symbolic name based on an entry beneath  /dev/disk/by-id,
              /dev/disk/by-path,  to reduce the risk of device nodes being renamed when new disks
              are added to the system, etc.

              sets configuration switches, such as
                * "user" (any user can mount),
                * "nouser" (only root can mount),
                * "fsck" (automatically check filesystem before mounting),
                * "nofsck" (don't check filesystem before mounting),
                * "mkswap" (format swap partition before use),
                * "nomkswap" (don't format swap partition)
                * "trim" (enable TRIM/discard support on solid-state disks),
                * "notrim" (disable SSD TRIM/discard support)
              This parameter is optional and defaults to "user,fsck,nomkswap,notrim".

              gives the number of sectors (512-byte blocks) into DEVICE at which  the  filesystem
              is to start.  This parameter is optional, and defaults to zero.

              gives  the  total  length  of  the  filesystem  in sectors (512-byte blocks).  This
              parameter is optional, and  defaults  to  -1  which  is  shorthand  for  the  total
              available length of DEVICE.

              can  be  used  to specify a particular loopback device (e.g. /dev/loop0) to be used
              when DEVICE is an ordinary file.   This  parameter  is  optional  and  defaults  to

       dir=MOUNT_POINT     (required)
              specifies the directory onto which the encrypted filesystem will be mounted.

       fstype=TYPE    (required)
              sets the filesystem type (as used by mount (8)).  This must be set to "swap" if the
              device is to be used as an encrypted swap partition.

              sets filesystem mounting options, as used by  mount  (8).  MOPT  can  typically  be
              "default", "noatime", "noexec", "nosuid", "ro", "sync" etc.

              sets  filesystem-checking  options  understood  by  fsck (8). FOPT can typically be
              "-C", "-V" etc.  Note that the list of fsck options uses semicolons as a  separator
              to allow passing options that themselves contain commas.

              sets  the  PATH  environment  variable when running subprocesses as the super-user.
              This may be necessary when commands such as fsck and mount need to run  subcommands
              (e.g. fsck.ext4).  By default, this PATH is set to /sbin:/bin:/usr/sbin:/usr/bin.

              indicates  what  action,  if any, should be taken for this target on system bootup.
              BOOTACTION can be one of "none", "mount", "swap" or  "prepare",  with  the  default
              being "none".

              sets  the  encryption  algorithm  used on the DEVICE.  The available algorithms are
              determined by the system kernel.  This parameter is optional and defaults to  "aes-

              specifies the key management scheme used to interact with the KEYFILE, as discussed
              in the CHOICE OF KEYMANAGER section below.  The set  of  available  key  management
              schemes  is  determined  when  cryptmount  is  built,  but may include "libgcrypt",
              "luks", and "openssl-compat", in addition to "builtin" and "raw".   This  parameter
              is optional: if absent, "builtin" will be used on first generating the key, with an
              automatic choice being made when reading a pre-existing key.

       keyfile=KEYFILE     (required)
              gives the name of an ordinary file  that  contains  the  key  used  by  the  CIPHER
              algorithm  to  decrypt  the  filesystem.  This  key  is  itself  encrypted in a way
              specified by the KEYHASH and KEYCIPHER

              sets the offset  added  to  the  sector-number  used  in  constructing  the  cipher
              algorithm's initialization vector.  This parameter is optional, and defaults to 0.

              is  the  hashing algorithm used to turn the user's password into the decryption key
              used by the KEYCIPHER algorithm.  The available hashing algorithms  are  determined
              by  the  chosen  key-encryption  engine specified by KEYMANAGER.  This parameter is
              optional and the default depends on the value of KEYMANAGER.

              is the encryption algorithm used to secure the decryption  key  of  the  filesystem
              itself.   The available key-encryption algorithms are determined by the chosen key-
              encryption engine specified by KEYMANAGER.  This  parameter  is  optional  and  the
              default depends on the value of KEYMANAGER.

              is  the  maximum  number  of  bytes  of  the  decryption key that will be read from
              KEYFILE.  This parameter is optional, and defaults to 0, indicating that  the  full
              length of KEYFILE should be read.

              is  the  number  of password-entry attempts that can be made before cryptmount will
              exit with an error-code when trying to mount or configure the target.


       cryptmount supports a variety of different ways of protecting the  access  key  associated
       with  each  encrypted  filesystem.   For most users, the default “builtin” keymanager will
       provide a good level of security and flexibility.  Alternative keymanagers offer  a  wider
       choice  of  different  password-hashing  schemes  and  compatibility with other encryption
       tools.  The strengths and weaknesses of the different keymanagers are discussed below.


       This keymanager is supported by cryptmount-2.0 or later, and uses a separate key-file.   A
       password-based  key derivation function (PBKDF) using the SHA1 hashing algorithm, together
       with blowfish-cbc encryption is used to protect the filesystem key.   That  key-derivation
       function  was  changed  in  cryptmount-4.0  to improve the security of new keyfiles, while
       preserving compatibility with existing keyfiles.  If you need to  write  keyfiles  in  the
       previous  format,  you  can  specify  “keyformat=builtin:0”.   The  KEYHASH  and KEYCIPHER
       parameters are ignored.


       This keymanager is supported by cryptmount-1.1 or later, and uses a separate key-file.   A
       password-based key derivation function (PBKDF) is used to protect the filesystem key, with
       any hashing or cipher algorithm supported  by  the  installed  version  of  the  libgcrypt
       library being available.


       This  keymanager  is supported by cryptmount-3.1 or later, and provided compatibility with
       the Linux Unified Key Setup (LUKS) disk-format.  Instead of a separate keyfile, LUKS  uses
       a header within the encrypted filesystem itself.  It is advisable to choose the same value
       for both the 'dev' and 'keyfile' parameters, or leave 'keyfile' unspecified.  As with  all
       cryptmount filesystems, the 'dev' parameter may point to either a raw disk partition or an
       ordinary file.  However, because of the  filesystem  structure  assumed  by  LUKS,  it  is
       strongly  recommended  that  you  do  not  use  either  the  'startsector'  or 'numsector'


       This keymanager has been supported since the earliest release of cryptmount,  and  uses  a
       separate  keyfile  which  is compatible with the format used by the 'openssl' command-line
       encryption tool.   Since  cryptmount-3.0  this  file-format  has  been  provided  via  the
       libgcrypt library, and is preferably specified by “keyformat=openssl-compat”.  A password-
       based key derivation function (PBKDF) is used to protect the filesystem key, with a choice
       of  hashing  or  cipher  algorithms  being  available.   Most  algorithms supported by the
       'openssl' command-line tool should be available, provided the  underlying  algorithms  are
       available within libgcrypt.


       This keymanager is supported by cryptmount-4.0 or later, and does not require any separate
       keyfile, but instead derives the filesystem key directly from the user's  password.   This
       means  that  it  is  not  possible to change the access password without re-encrypting the
       entire filesystem.  The 'keyhash' and 'keycipher' parameters are ignored.


       This keymanager is supported by cryptmount-1.1 or later, and uses a separate keyfile where
       the  access  key  is  stored directly and without any encryption.  This keymanager is most
       useful for managing encrypted  swap  partitions,  where  the  keyfile  can  be  chosen  as
       /dev/random,  and  hence where the access key will be different every time it is read.  If
       the keyfile is an ordinary file, it offers minimal  security,  and  should  preferably  be
       stored  separately  from the disk containing the encrypted filesystem, e.g. on a USB flash


       Because cryptmount needs to operate with setuid privileges, it is very important that  its
       configuration  file  is kept secure.  Ideally /etc/cryptmount/cmtab should be managed only
       by the system administrator, and all key-files should be readable only by their owner.

       cryptmount makes basic checks on the security of /etc/cryptmount/cmtab each time it  runs,
       and will refuse to operate unless the following conditions are met:
         * cmtab must be owned by root
         * cmtab must be a regular file
         * cmtab must not be globally writable
         * the directory containing cmtab must be owned by root
         * the directory containing cmtab must not be globally writable
       In  addition,  for  each  target  within @CM_SYSCONFDIR@/cmtab, all paths must be absolute
       (i.e. starting with '/').

       When using unencrypted keyfiles (i.e. when KEYMANAGER is "raw"), it  is  recommended  that
       the  KEYFILE  is  stored  with  access  permissions no less restrictive than 0600, or on a
       removable device such as a USB  flash-disk.   (With  recent  versions  of  cryptmount  the
       "builtin"  key-format  should  be portable between different installations and vastly more
       secure than "raw" keyfiles.)

       It is very important that you do not lose or damage the KEYFILE as this file is  essential
       to  providing  access  to your encrypted filesystem.  You are strongly advised to consider
       keeping a backup of your KEYFILE in some form.


       When the 'mkswap' option is selected for a particular target within @CM_SYSCONFDIR@/cmtab,
       cryptmount  will  attempt to automatically format an encrypted swap partition whenever you
       run "cryptmount --swapon <target>".  This is  often  useful  when  there  is  no  need  to
       preserve  swap  data  between  reboots,  such  as  when not using the kernel's hibernation

       Because reformatting will  destroy  any  existing  data  on  the  chosen  swap  partition,
       cryptmount  will  do  some basic checking on the first megabyte of the partition, based on
       the degree of randomness (entropy) in the current contents.  If the partition  looks  like
       it  contains  pure  noise,  or  has  been  zeroed,  then  the  partition will be formatted
       automatically.  If cryptmount determines that the partition may contain  non-random  data,
       then it will ask you to run 'mkswap' manually.

       As  there  is  no  fool-proof  way  of  determining  whether a partition (especially after
       encryption) contains valuable data, you should be very careful about the raw device chosen
       for any target on which you select the 'mkswap' option.


       The  following  example of @CM_SYSCONFDIR@/cmtab consists of five targets, using a variety
       of encryption algorithms and storing their filesystems  in  different  ways,  including  a
       target representing an encrypted swap partition:

           # @CM_SYSCONFDIR@/cmtab
           # example file - please modify before use

           _DEFAULTS_ {
               passwdretries=3     # allow 3 password attempts by default

           basic {
               dir=/home/secretiveuser/crypt           # where to mount
               loop=auto                               # find free loop-device
               fstype=ext3     mountoptions=default
               cipher=aes-cbc-plain                    # filesystem encryption
               # use default sha1/blowfish key-encryption:

           partition {
               dev=/dev/hdb62                      # use whole disk partition
               fstype=ext3     mountoptions=nosuid,noexec

               # information about file used to store decryption key:
               keyformat=openssl                   # use OpenSSL key-encryption
               keyhash=md5 keycipher=bf-cbc        # encryption of key file

           subset {
               startsector=512 numsectors=16384    # use subset of partition
               dir=/mnt/encrypted\ subset\ of\ hdb
               fstype=reiserfs     mountoptions=defaults
               cipher=twofish-cbc-plain            # filesystem encryption

               # information about file used to store decryption key:
               keyhash=md5 keycipher=blowfish-cbc # encryption of key file

           encswap {                               # encrypted swap partition
               startsector=16896 numsectors=1024   # use subset of partition
               fstype=swap        flags=mkswap       cipher=twofish-cbc-plain

               # read fresh 16-byte key from /dev/random whenever used:
               keyfile=/dev/random        keymaxlen=16     keyformat=raw

           luks {                          # partition created by cryptsetup-luks

           # end of cmtab

       The  'basic'  target  uses  an  ordinary  file "/home/secretiveuser/crypt.fs" to store the
       encrypted filesystem, perhaps within a normal user's home directory.   A  loopback  device
       will  be  automatically  allocated (because of the "loop=auto") by cryptmount to turn this
       into a block-special device, before mounting.  The decryption key for  the  filesystem  is
       also  stored  in  this  user's  home  directory,  making  it easier for them to change the
       password protecting the key.

       The 'partition' target uses a whole disk partition to store the encrypted filesystem, with
       the decryption key stored in the main cryptmount configuration directory.

       The  'subset'  target  is  similar to the 'partition' target except that it does not use a
       whole disk partition.  This would allow other groups of blocks within that partition to be
       used for other filesystems managed via cryptmount or dmsetup.

       The  'encswap' target uses a subset of blocks within a disk partition to form an encrypted
       swap device.  A new encryption  key  is  read  from  the  system  random-number  generator
       /dev/random every time the target is used.

       The  'luks'  target  provides access to an encrypted partition created by the 'cryptsetup-
       luks' utility.  By using the environmental variable $(USERNAME), the  filesystem's  mount-
       point will vary depending on which user invokes cryptmount.  For example, user 'joe' would
       find the filesystem mounted below /mnt/luks-partition-joe.  cryptmount  will  be  able  to
       mount  and  unmount  the  partition,  but  various advanced LUKS features must be accessed
       through cryptsetup


       /etc/cryptmount/cmtab - main configuration file


       cryptmount(8), cryptmount-setup(8), cryptsetup(8), dmsetup(8), openssl(1)


       cryptmount is Copyright 2005-2021 RW Penney
       and is supplied with NO WARRANTY.  Licencing terms are as described in the file  "COPYING"
       within the cryptmount source distribution.