pam_mount module Activity
Brought to you by:
jengelh
Activity for pam_mount module
-
Dmitry-T posted a comment on merge request #7
I proceeded from the fact that my solution already allows mounting, since "sep=" is implemented in the Linux kernel. In other words: there is "sep" in the OS kernel, there is "sep" in the documentation, and I just updated the utilities in user space. If the Linux kernel provided another mechanism, then I would use it.
-
Jan Engelhardt posted a comment on merge request #7
sep has the problem that you always have to give up a particular character. A better approach would be to implement escape sequences, which is a true-and-tried method across Unix history. An extra mount parameter will be needed to tell whether to interpret uncpath the classic way, or whether to apply some form of unescape processing. I can think of two syntax options: mount.cifs '//localhost/block 3,4' /tmp -o 'enc=1,unc=\\\\localhost\\block 3\,4' mount.cifs '//localhost/block 3,4' /tmp -o 'enc=2,unc=\\localhost\block...
-
A patch to implement the already documented "sep" option for the CIFS file system.
-
Maarten Grachten created ticket #132
Piping password to mount.crypt fails with "no free loop devices"
-
Jochen Sprickerhof created merge request #6
Add ignoresource option
-
pam_mount module released /pam_mount/pam_mount-2.19.tar.xz
-
-
pam_mount 2.19
-
doc: switch news.txt to rST
-
doc: remove old changelog entries
-
oficsu posted a comment on merge request #5
Thank you very much! I would like to see the changes in my Linux distro, so can I expect v2.19 to be released soon, or is there anything I could do to help with the release? :)
-
add support for detached headers
-
I have taken 9eea372, and edited it for style (e.g. fixed the odd indent in src/crypto.c) and doc.
-
pam_mount: add support for detached headers
-
I've prepared an alternative squashed branch [diff] which is based on top of the current master and can be merged without any conflicts. Should I now update this merge request to use the detached-headers-squashed as a source branch?
-
I've prepared an alternative squashed branch which is based on top of the current master and can be merged without any conflicts. Should I now update this merge request to use the detached-headers-squashed as a source branch?
-
I think the PR is ready. The manual tests I made on each new commit: creating an image without a detached header mounting this image with mount.crypt umounting After the pmt-ehd: add support for detached headers, the following tests: creating an image with a detached header mounting this image with mount.crypt (manually and on login) creating an image with exactly the same path to the image and header mounting the previous image with -oheader=... and without it, both work correctly umounting If we...
-
I think the PR is ready. The manual tests I made on each new commit: creating an image without a detached header mounting this image with mount.crypt umounting After the pmt-ehd: add support for detached headers, the following tests: creating an image with a detached header mounting this image with mount.crypt (manually and on login) creating an image with exactly the same path to the image and header mounting the previous image with -oheader=... and without it, both work correctly umounting If we...
-
I think the PR is ready. The manual tests I made on each new commit: creating an image without a detached header mounting this image with mount.crypt umounting After the pmt-ehd: add support for detached headers, the following tests: creating an image with a detached header mounting this image with mount.crypt (manually and on login) creating an image with exactly the same path to the image and header mounting the previous image with -oheader=... and without it, both work correctly umounting If we...
-
Oh, I've missed that some patches from work-in-progres branch are already in upstream :) Should I do something about the merge conflict?
-
Oh, I've missed that some patches from work-in-progres branch are already in upstream :) Should I do something with merge conflict?
-
I think the PR is ready. The manual tests I made on each new commit: creating an image without a detached header mounting this image with mount.crypt umounting After the pmt-ehd: add support for detached headers, the following tests: creating an image with a detached header mounting this image with mount.crypt (manually and on login) creating an image with exactly the same path to the image and header mounting the previous image with -oheader=... and without it, both work correctly umounting If we...
-
add support for detached headers
-
@jengelh, thanks a lot! I've already added a header support to pmt-ehd (mainly because the previous changes broke it and I needed to do some research about how pmt-ehd works). And it seems, realpath is really needed... but in pmt-ehd (when a user passes the same path to header and container arguments) I've already added realpath to mtcrypt.c to just make it more consistent with other paths and I will add it soon to ehd.c, remove mention of crypttab, add some documentation changes. And then, I'm going...
-
Should we use crypttab Leaning towards no. crypttab is for boot-time volumes, or rather, static system volumes. The pmt-ehd is totally new to me. Should I add support for it? You can, but it probably isn't worth the time. The utility existed/exists to facilitate plain dm-crypt volumes when LUKS was new.
-
I incorporated b6dbd44, with some WS and spellos addressed. Realpath When a path is fed into a system routine and later retrieved again. The equivalency between /tmp/../mnt and /mnt needs to be taken into account when comparing strings. This is generally limited to the source device and the mountpoint directory. The LUKS header path is never read from /etc/mtab|/proc/mounts again, is it.. (e.g. mount /dev/./sda1 /tmp/../mnt is likely to get resolved to /dev/sda1 and /mnt respectively by the mount(2)...
-
Add initial support for LUKS detached headers
-
Merge branch 'fix-117' of https://git.code.sf.net/u/ojford/pam-mount
-
As I can see, the remount option works correctly even without any additional fixes due to the actual implementation doesn't really reopen the luks container but remounts filesystem only. It does not allow you to change such options as crypto_name or allow_discards, but I think it is out of scope of this PR
-
I've made more patches. Some of them are just minor refactoring/fixes, but a few commits are rdconf updates. This works perfectly on my laptop, but I still have some questions: Realpath. Shouldn't I get the header realpath here? Do we need it for mtab? What is the correct way to get it using HX library? Memory management. I'm not very familiar with the project structure and the C language in general, so I could leave a leak somewhere. Foremost, I'm interested in this and this. It seems that the correct...
-
Initial changes already can be found here: branch, diff
-
Initial changes already can be found here: branch, diff
-
add detached headers support
-
Segfault with parallel PAM transactions
-
Jens Flemming created ticket #130
Segfault with parallel PAM transactions
-
This does not work for me, vpt->volume and vpt->combopath are the same for me (/dev/disk/by-label/<label>) and different to source (currently proc, not sure why).
-
Anton Shevtsov posted a comment on ticket #63
i need its feature too. Or, remount on-demand. Or, reconnect if server available again.. something tool for start remount process again
-
Robin posted a comment on ticket #127
Now to get the web site updated as well as the news to indicate that pam_mount is updated to support luks2. Web site says 2.15 was released in 2014.
-
Exclude local users
-
"use_first_pass" should not be in the doc?
-
The news.txt entry referred to pam_mount's use_first_pass flag. I have clarified this.
-
doc: update changelog entry for use_first_pass removal
-
DTD is out of date (does not define regex attribute on user element)
-
Cannot reproduce with v2.18. The regex attribute was added to the DTD in v2.15-1-gc28ce7c .
-
Console output even with <debug enable="0" /> (regex="yes")
-
Should be addressed by v2.18-5-g9924c48 .
-
pam_mount: reduce log verbosity of pcre messages
-
src: style adjustments
-
doc: add missing .TP markup
-
pam_mount uses deprecated openssl 1.1 features
-
Fixed by v2.18-1-g851aa02.
-
luks2 support missing
-
Fixed by v2.16-1-gd4434c0 (-> v2.17)
-
Viktor created merge request #4
no_read_workqueue and no_write_workqueue flags
-
OJFord posted a comment on merge request #3
I have no idea how to submit a merge request on Sourceforge, just created an account to say I've added a further fix for this to address the similar issue for FUSE mounts mentioned by @floris in a comment on #117. You're welcome to pull that in here if you think it suitable: https://sourceforge.net/u/ojford/pam-mount/ci/35273d68079348b6a73e0a14b25658434aeefc07/
-
Guillaume Rousse created ticket #129
mount.crypt doesn't work, but returns successfully
-
libcryptmount: drop deprecated openssl functions for >= 1.1
-
-
-
pam_mount 2.18
-
Evan Linde created merge request #3
Use combopath when detecting already-mounted filesystems
-
src: use *_cast macros in rdconf1.c
-
doc: add sshfs without fd0ssh example
-
build: add missing include for HX_readlink
-
build: change regex API to use PCRE2
-
src: compress include list for ehd.c
-
doc: add missing ssh=1 parameter for fd0ssh-based sshfs
-
doc: fix fd0ssh name according to version in hxtools
-
src: declare array size to fix build failure
-
mount.crypt: ignore fstype=crypt to cure a recursive exec
-
pmvarrun: get rid of PATH_MAX limit
-
build: drop doc/pam_mount.txt
-
doc: highlight fd0ssh's use of askpass mechanism
-
doc: fix "nfs and nfs" wording
-
doc: fix manpage spellos
-
pam_mount: allow luserconf outside home directory
-
doc: update support page links
-
src: remove unnecessary libssl include in mtcrypt.c
-
-
-
build: abandon ssbindir
-
build: cure -Wstringop-truncation compiler warning
-
pam_mount 2.17
-
The default is pretty sensible, because 1. most CIFS servers are likely of the Windows kind (I have no stats) and do not have Unix extensions. 2. Mounting a Windows or Samba share without uid= causes all files to belong to root if there are no Unix extensions in effect. 3. There is no known way to determine if Unix extensions are in effect. Overriding the cifsmount command in the config file is the recommended way to proceed.
-
kiwifb posted a comment on ticket #120
In fact noforceuid/gid is very poorly understood. From https://www.kernel.org/doc/readme/Documentation-filesystems-cifs-README noforceuid Fill in file owner information (uid) by requesting it from the server if possible. With this option, the value given in the uid= option (on mount) will only be used if the server can not support returning uids on inodes. In my case I don't want uid= to be defined ever because noforceuid still wants to apply some uid from the server in that case. Which is inappropriate...
-
Resurecting this. I am part of a university and we do have unix style extension. And not being able to turn off uid= just cause the mount to fail with permission denied. I tried to use noforceuid and noforcegid in options but that didn't work.May be I didn't understand where it is supposed to go. Sensible default are a good thing, being able to change them is an even better thing. Is the only way to get rid of this to redefine the mount command for cifs?
-
conloos created ticket #128
pmvarrun error by using sssd
-
michael b modified a comment on ticket #65
Thanks for the reply. I have since edited that actually but still no luck. Not sure if it makes any sense now post-edit, but here is the new system-auth. Could you suggest a re-ordering of the lines in this file? I admit I'm out of my swimlane with PAM config... Or perhaps there is a different file I need to edit/create. I do not have a system-login file... but did try adding these lines also to my sshd file... ##%PAM-1.0 ## This file is auto-generated. ## User changes will be destroyed the next...
-
Thanks for the reply. I have since edited that actually but still no luck. Not sure if it makes any sense now post-edit, but here is the new system-auth. Could you suggest a re-ordering of the lines in this file? I admit I'm out of my swimlane with PAM config... ##%PAM-1.0 ## This file is auto-generated. ## User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth [default=1 ignore=ignore success=ok] pam_succeed_if.so...
-
Thanks for the reply. I have since edited that actually but still no luck. Not sure if it makes any sense now post-edit, but here is the new system-auth. Could you suggest a re-ordering of the lines in this file? I admit I'm out of my swimlane with PAM config... %PAM-1.0 This file is auto-generated. User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >=...
-
Thanks for the reply. I have since edited that actually but still no luck. Not sure if it makes any sense now post-edit, but here is the new system-auth %PAM-1.0 This file is auto-generated. User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet auth [default=1 ignore=ignore success=ok] pam_localuser.so auth required pam_mount.so auth sufficient...
-
Your PAM config makes no sense. The auth optional pam_mount.so line is only executed when pam_deny.so is. Therefore, the session part of pam_mount.so has no password available.
-
x-posted here since it seems this group doesn't get much traffic https://stackoverflow.com/questions/59011078/rhel7-pam-mount-trouble-for-ad-accounts
-
RHEL7, pam_mount trouble for AD accounts
-
I will second this report. A new install on Fedora 31, pam_mount will not work and user directories now have to be manually mounted. There is code that will allow pam_mount to work with LUKS2 that has been out for almost a year but not implemented yet. https://bbs.archlinux.org/viewtopic.php?id=242131 Still trying to get a work around.
-
eatdirt created ticket #127
luks2 support missing
-
Eduardo Moraes created ticket #126
pam_mount does not mount the volumes that contain defined control attributes (user, pgrp, sgrp, uid, and gid)
-
Hanno Böck created ticket #125
pam_mount uses deprecated openssl 1.1 features
-
pam_mount does not work with LUKS2 volumes
-
crypto: Add support for LUKS2
1 >