Provided by: libpam-mount_2.14-1_i386 bug

Name

       pam_mount - A PAM module that can mount volumes for a user session

Overview

       This  module  is aimed at environments with central file servers that a
       user  wishes  to  mount  on  login  and  unmount  on  logout,  such  as
       (semi-)diskless   stations   where  many  users  can  logon  and  where
       statically mounting the entire /home from a server is a security  risk,
       or listing all possible volumes in /etc/fstab is not feasible.

       ·   Users can define their own list of volumes without having to change
           (possibly non-writable) global config files.

       ·   Single sign-on feature - the user needs to type the  password  just
           once (at login)

       ·   Transparent mount process

       ·   No stored passwords

       ·   Volumes  are  unmounted on logout, freeing system resources and not
           leaving data exposed.

       The module also supports mounting local filesystems  of  any  kind  the
       normal  mount  utility  supports,  with extra code to make sure certain
       volumes are set up properly because often they need more  than  just  a
       mount  call,  such  as encrypted volumes. This includes SMB/CIFS, FUSE,
       dm-crypt and LUKS.

       If you intend to use pam_mount to  protect  volumes  on  your  computer
       using  an  encrypted filesystem system, please know that there are many
       other issues you need to consider in order to protect  your  data.  For
       example,  you  probably  want to disable or encrypt your swap partition
       (the cryptoswap can help you do this). Do not assume a system is secure
       without carefully considering potential threats.

Configuration

       The   primary   configuration   file   for   the  pam_mount  module  is
       pam_mount.conf.xml.   On  most  platforms  this  file  is   read   from
       /etc/security/pam_mount.conf.xml.   On   OpenBSD  pam_mount  reads  its
       configuration file from /etc/pam_mount.conf.xml.  See pam_mount.conf(5)
       documenting its use.

       Individual  users  may define additional volumes to mount if allowed by
       pam_mount.conf.xml (usually ~/.pam_mount.conf.xml). The volume  keyword
       is the only valid keyword in these per-user configuration files. If the
       luserconf parameter is set in pam_mount.conf.xml, allowing user-defined
       volume,  then  users  may  mount and unmount any volume they own at any
       mount point they own. On some filesystem configurations this may  be  a
       security  flaw  so  user-defined volumes are not allowed by the example
       pam_mount.conf.xml distributed with pam_mount.

PAM configuration

       In addition, you must include two entries in  the  system's  applicable
       /etc/pam.d/service config files, as the following example shows:

                  auth     required  pam_securetty.so
                  auth     required  pam_pwdb.so shadow nullok
                  auth     required  pam_nologin.so
              +++ auth     optional  pam_mount.so
                  account  required  pam_pwdb.so
                  password required  pam_cracklib.so
                  password required  pam_pwdb.so shadow nullok use_authtok
                  session  required  pam_pwdb.so
                  session  optional  pam_console.so
              +++ session  optional  pam_mount.so

       When "sufficient" is used in the second column, you must make sure that
       pam_mount is added before this entry. Otherwise pam_mount will not  get
       executed  should  a  previous  PAM module succeed. Also be aware of the
       "include" statements. These make PAM look into the specified  file.  If
       there is a "sufficient" statement, then the pam_mount entry must either
       be in the included file before the "sufficient" statement or before the
       "include" statement.

       If  you use pam_ldap, pam_winbind, or any other authentication services
       that make use of PAM's sufficient keyword, model your configuration  on
       the following order:

              ···
              account sufficient  pam_ldap.so
              auth    required    pam_mount.so
              auth    sufficient  pam_ldap.so use_first_pass
              auth    required    pam_unix.so use_first_pass
              session optional    pam_mount.so
              ···

       This allows for:

       1.  pam_mount,  as  the first "auth" module, will prompt for a password
           and export it to the PAM system.

       2.  pam_ldap will use the password from  the  PAM  system  to  try  and
           authenticate   the  user.  If  this  succedes,  the  user  will  be
           authenticated. If it fails, pam_unix will try to authenticate.

       3.  pam_unix will try to authenticate the user if pam_ldap  failed.  If
           pam_unix fails, then the authentication will be refused (due to the
           "required").

       Alternatively, the following is possible (thanks to Andrew  Morgan  for
       the hint!):

              auth [success=2 default=ignore] pam_unix2.so
              auth [success=1 default=ignore] pam_ldap.so use_first_pass
              auth requisite pam_deny.so
              auth optional pam_mount.so

       It  may  seem  odd,  but  the first three lines will make it so that at
       least one of pam_unix2 or pam_ldap has to  succeed.  As  you  can  see,
       pam_mount  will  be  run  after  successful  authentication  with these
       subsystems.

Encrypted disks

       pam_mount supports a few types of crypto. The most  common  are  encfs,
       dm-crypt and dm-crypt+LUKS.

       The first one uses the FUSE layer; files within the encfs container are
       stored as single encrypted files on the host in  a  previously-existing
       directory.  If  you  store  lots  of files, it is recommended to have a
       lower filesystem that is strong in this area, such  as  xfs,  but  some
       software  and/or  your  partitioning  decisions  may force you to use a
       different fs. The 1:1 mapping of files also allows encrypted  files  to
       be  reasonably  efficiently rsync'ed for example without having to open
       the encrypted container. Creation is done through the encfs(1) tool.

       dm-crypt provides whole-filesystem/entire-partition encryption. You can
       also create a container file, but the idea is that it is represented as
       a block device on which you still have to create a filesystem. In fact,
       this  way  you  can select a filesystem of your choice. The downside is
       that shrinking is often not possible (there is no such issue  in  encfs
       because  it  uses  the  lower  fs).  Suitable  dm-crypt containers (and
       auxiliary files), using block devices or plain files,  can  be  created
       using the pmt-ehd(8) tool.

       pmt-ehd  creates  filesystem  key  material  which is a bunch of random
       bytes that will be used to en-/decrypt the volume. This material itself
       is  encrypted  with  your  own  password - this is done so that you can
       change the password without having to reencrypt all of your data.

       LUKS is an extension for dm-crypt to support multi-password containers.
       Unless   you   specifically  need  it,  the  above  two  solutions  are
       recommended.

       NOTE:  The  key  file  that  pmt-ehd(8)  will  create  represents   the
       filesystem  key  material  as  encrypted with your password. It is thus
       safe to store this on an unsecured filesystem.

Troubleshooting

       To ensure that your system and, possibly, the  remote  server  are  all
       properly configured, you should try to mount all or some of the volumes
       by  hand,  using  the  same  commands  and  mount  points  provided  in
       pam_mount.conf.xml. This will save you a lot of grief, since it is more
       difficult to debug the mounting process via pam_mount.

       If you can mount the volumes by  hand  but  it  is  not  happening  via
       pam_mount,   you   may   want   to   enable   the   "debug"  option  in
       pam_mount.conf.xml to see what is happening.

       Verify if the user owns the mount point and has sufficient  permissions
       over  that.  pam_mount  will  verify  this and will refuse to mount the
       remote volume if the user does not own that directory.

       If pam_mount is having trouble unmounting  volumes  upon  logging  out,
       enable  the  debug variable. This causes pam_mount to run ofl on logout
       and write its output to the system's log.

Authors

       W. Michael Petullo

       Jan Engelhardt (current maintainer)

Community Support

       The following two forms of communication are available. The  maintainer
       has no preference, though you will reach more users who could answer by
       means of the mailing list.

       Mailing List:
              http://sf.net/mail/?group_id=41452

       Bug Tracker (no registration needed):
              http://sf.net/tracker/?group_id=41452