Man Linux: Main Page and Category List


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


       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.


       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
                  auth     required shadow nullok
                  auth     required
              +++ auth     optional
                  account  required
                  password required
                  password required shadow nullok use_authtok
                  session  required
                  session  optional
              +++ session  optional

       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
              auth    required
              auth    sufficient use_first_pass
              auth    required use_first_pass
              session optional

       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

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

              auth [success=2 default=ignore]
              auth [success=1 default=ignore] use_first_pass
              auth requisite
              auth optional

       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 authentification with these

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

       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.


       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.


       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:

       Bug Tracker (no registration needed):