1) use umask determined mount options rather than hardcoded options A filesystem can generally be mounted privately for a single user/group or shared. It should be a sane default to mount privately. I.e. this is with the system's umask. (When detecting the umask note that umask might be set diferently for root, and thus for the running script than for the users) Optionally provide an option to mount with less (i.e. userdefined) restrictions/other group. (Might be fixed upstream already.) For best VFAT integration not only on multi user systems here are tested mount options: On systems that use umask 002 add ",quiet,shortname=mixed,dmask=0002,fmask=0113" to the vfat mount options. On systems with umask 022 add ",quiet,shortname=mixed,dmask=0022,fmask=0133" to the vfat mount options. Non-english systems benefit using multilingual codebase with ",codepage=850" in the vfat mount options. If the system uses UTF8 also add ",iocharset=utf8" to the vfat mount options. 2) mount races Users should be able to trust their media. Example: If one user inserts a medium in a drive or plugs it into a connector onother user could mount and have the media manipulated before the owner gets to it. Same between unmounting and ejecting/unplugging. Not only for this case some kind of locking mechanism would be needed. Unfortunately there was no developer reaction upon a query on the list: http://mail.gnome.org/archives/utopia-list/2005-October/msg00034.html
Hello,
A long time ago, you reported an issue about possible mount races
for the pmount program [1]. pmount provides a locking mechanism. Is
that what you were looking for, or did you have something else in mind
? If that is the case, could you please elaborate ?
Thanks,
Vincent Fourmond
[1]: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431286
Hi, thank you for checking back. What I understand from the man page the pmount --lock option prevents mounting _during_ the locked period. In order to mount the device one would need to unlock it and then mount it (still in competition to other users/programs). Maybe what was meant should rather be called something different then locking. Perhaps reserving, blocking, booking, scheduling, claiming,...? of devices or might be more precise. Topic 2) in the original bugreport addresses removable (usb etc.) devices pluged into a multi-user system whith several users loged in simultaniously, i.e. terminal servers, multi-seat systems, or over the network etc. I was looking for a way to ensure that the owner of say an usb-stick that plugs it into the multi-seat system he works on is also the only one to read/write his usb-stick. One idea would be for the user to be able to "lock" or better reserve/schedule whatever the mounting of the (next) removable media. Making sure no other users sneek in on his usb-stick in the time between insertion and him mounting his device or unmounting and him unpluging his media. The provided link in the first message might also give more of an idea.--- I did make the mistake to mix two topics in one report. :( Could the optimized mount options described under 1) already get implemented? Like mounting with --private or --public permissions, tweaking the permissions depending on current umask settings, filesystems (vfat) and locale (utf8)? That would be great, no splitting of the report necessary then. OTH that might be somthing for the hal-package, could you duplicate the issue reassigning part 1) in that case? Thank you again for checking back on this report. Christian
Hello, C. Gatzemeier wrote: As far as I can tell, this is technically difficult. What would be the mechanism to reserve the device ? What happens when two users try to reserve the same device at the same time ?? For me, it seems to only push the problem earlier in time, but that wouldn't solve it : nothing could prevent a malicious user to permanently lock all the devices, and you wouldn't be able to access your data as well. One way might be to reserve the use of pmount to physically logged-in users, but that isn't always a good idea (think about, say, SMB shares, or even local hard-drives that are not permanently mounted for some reasons)... I now see better the problem which you are rising, but I currently don't see any technical solution - or at least, none that would be more fool-proof than the current (non) solution. My advice would be to resort to cryptography, if you fear for the safety of your data; pmounts handles that transparently (devices created with luksformat). I agree however that it wouldn't be convenient Yes, very bad ;-)... That's why I split the reports in the end. Currently, pmount /dev/something mounts it privately (for filesystems that don't support permissions, others are not affected). pmount -u 022 /dev/something mounts it with umask = 022. That's basically your --public/--private options, except they have slightly different names. UTF8 is slightly more complex, as the Linux Kernel doesn't support UTF8 very well with FAT, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443514 I considered this part of the request to be implemented. You're welcome ;-) ! Regards, Vincent
We believe that the bug you reported is fixed in the latest version of
pmount, which is due to be installed in the Debian FTP archive:
pmount_0.9.99-alpha-1.debian.tar.gz
to main/p/pmount/pmount_0.9.99-alpha-1.debian.tar.gz
pmount_0.9.99-alpha-1.dsc
to main/p/pmount/pmount_0.9.99-alpha-1.dsc
pmount_0.9.99-alpha-1_amd64.deb
to main/p/pmount/pmount_0.9.99-alpha-1_amd64.deb
pmount_0.9.99-alpha.orig.tar.bz2
to main/p/pmount/pmount_0.9.99-alpha.orig.tar.bz2
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 431286@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Vincent Fourmond <fourmond@debian.org> (supplier of updated pmount package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
Format: 1.8
Date: Fri, 25 Mar 2011 20:03:07 +0100
Source: pmount
Binary: pmount
Architecture: source amd64
Version: 0.9.99-alpha-1
Distribution: experimental
Urgency: low
Maintainer: Vincent Fourmond <fourmond@debian.org>
Changed-By: Vincent Fourmond <fourmond@debian.org>
Description:
pmount - mount removable devices as normal user
Closes: 373580 431286 488627 513431 542779 615979 616019
Changes:
pmount (0.9.99-alpha-1) experimental; urgency=low
.
* New upstream experimental release, bringing in a lot of new features:
- fscking (closes: #513431, #488627, #542779, since all of these bugs,
though different, come from the impossibility to run fsck on a
filesystem before mounting)
- now by default forbidding mounts by users not physically logged in,
which prevents mount races (closes: #431286)
- whitelisting firewire (closes: #616019)
- checking the sanity of the target device before attempting to mount
it, which in particular prevents long errors with a 'no medium found'
error (closes: #615979)
- finally opening the possibility to mount user images through loop
devices (closes: #373580)
* Added a news entry about the new configuration file
* Update watchfile to accept -alpha in the release number
Checksums-Sha1:
9ed59692d333c2fda0377d33a3b8775112721e9c 1178 pmount_0.9.99-alpha-1.dsc
091ab70d85bf2c62013134b23a16acb363b63777 364282 pmount_0.9.99-alpha.orig.tar.bz2
9632aaec04f47c1b0be7716ee35efd8a15914170 11722 pmount_0.9.99-alpha-1.debian.tar.gz
5e5627a1d24aa073974f2eec90c15775f3a37daa 122338 pmount_0.9.99-alpha-1_amd64.deb
Checksums-Sha256:
7598131515c01a56c79fc83c8d0d974a790afb810f7923ad5eafed24d849c1c3 1178 pmount_0.9.99-alpha-1.dsc
ca06bd0c429d3db9382433f378d07bf763534f70fe71015322678e321b0679e5 364282 pmount_0.9.99-alpha.orig.tar.bz2
d3ec949de9b0ce4f0a9c5c4fd6e131c9458aa48848f9075f06f84b2aaf516e1b 11722 pmount_0.9.99-alpha-1.debian.tar.gz
4ee6d57b6cc623b83289196a7f549e9f4a0249e68e4d56320c772ff0a81cda12 122338 pmount_0.9.99-alpha-1_amd64.deb
Files:
5020189869b2102d7dfc99f4a6885215 1178 utils optional pmount_0.9.99-alpha-1.dsc
39bfeb1d3aa80ffec06c39ac9c62769e 364282 utils optional pmount_0.9.99-alpha.orig.tar.bz2
38e413f9539357fd3f5c7d959878908f 11722 utils optional pmount_0.9.99-alpha-1.debian.tar.gz
d8302a0fa7185a8f5d302effaa034784 122338 utils optional pmount_0.9.99-alpha-1_amd64.deb
iEYEARECAAYFAk2M6cgACgkQx/UhwSKygsp3rACfeUmyZE1T5sA5YUYVvb+XTsOt
AGMAnAhNyNENEKlsyUg3vVhTqzwhDBuS
=f8iM
-----END PGP SIGNATURE-----