Re: [ANNOUNCE] util-linux-ng 2.13.1 (stable)
On Wed, 16 Jan 2008, Karel Zak wrote: mount: - doesn't drop privileges properly when calling helpers [Ludwig Nussel] How can a mount helper know without being setuid root and redundantly doing mount(8)'s work that the user is allowed to mount via the 'user[s]' fstab mount option? Szaka -- NTFS-3G: http://ntfs-3g.org - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] util-linux-ng: unprivileged mounts support
On Wed, 16 Jan 2008, Miklos Szeredi wrote: This is an experimental patch for supporing unprivileged mounts and umounts. User unmount unfortunately still doesn't work if the kernel doesn't have the unprivileged mount support but as we discussed this in last July that shouldn't be needed for this case. % mount -t ntfs-3g /dev/hda10 /tmp/test % cat /proc/mounts | grep /tmp/test /dev/hda10 /tmp/test fuseblk rw,nosuid,nodev,user_id=501,group_id=501,allow_other 0 0 % mount | grep /tmp/test /dev/hda10 on /tmp/test type fuseblk (rw,nosuid,nodev,allow_other,blksize=1024,user=szaka) % umount /tmp/test umount: /dev/hda10: not mounted umount: /tmp/test: must be superuser to umount umount: /dev/hda10: not mounted umount: /tmp/test: must be superuser to umount Szaka -- NTFS-3G: http://ntfs-3g.org - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] util-linux-ng: unprivileged mounts support
On Sat, 19 Jan 2008, Miklos Szeredi wrote: But 'fusermount -u /tmp/test' does work, doesn't it? You're submitting patches to get rid of fusermount, aren't you? Most users absolutely have no idea what fusermount is and they would __really__ like to see umount(8) working finally. Szaka -- NTFS-3G: http://ntfs-3g.org - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck)
On Tue, 15 Jan 2008, Daniel Phillips wrote: Along with this effort, could you let me know if the world actually cares about online fsck? Now we know how to do it I think, but is it worth the effort. Most users seem to care deeply about things just work. Here is why ntfs-3g also took the online fsck path some time ago. NTFS support had a highly bad reputation on Linux thus the new code was written with rigid sanity checks and extensive automatic, regression testing. One of the consequences is that we're detecting way too many inconsistencies left behind by the Windows and other NTFS drivers, hardware faults, device drivers. To better utilize the non-existing developer resources, it was obvious to suggest the already existing Windows fsck (chkdsk) in such cases. Simple and safe as most people like us would think who never used Windows. However years of experience shows that depending on several factors chkdsk may start or not, may report the real problems or not, but on the other hand it may report bogus issues, it may run long or just forever, and it may even remove completely valid files. So one could perhaps even consider suggestions to run chkdsk a call to play Russian roulette. Thankfully NTFS has some level of metadata redundancy with signatures and weak checksums which make possible to correct some common and obvious corruptions on the fly. Similarly to ZFS, Windows Server 2008 also has self-healing NTFS: http://technet2.microsoft.com/windowsserver2008/en/library/6f883d0d-3668-4e15-b7ad-4df0f6e6805d1033.mspx?mfr=true Szaka -- NTFS-3G: http://ntfs-3g.org - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 7/9] unprivileged mounts: allow unprivileged fuse mounts
Hi, On Wed, 9 Jan 2008, Nigel Cunningham wrote: On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote: For the suspend issue, there are also no easy solutions. What are the non-easy solutions? A practical point of view I've seen only fuse rootfs mounts to be a problem. I remember Ubuntu patches for this (WUBI and some other distros install NTFS root). But this probably also depends on the used suspend implementation. Personally I've never had fuse related suspend problem with ordinary mounts during heavy use under development, nor NTFS user problem was tracked down to it in the last one and half year. Regards, Szaka -- NTFS-3G: http://ntfs-3g.org - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 5/9] unprivileged mounts: allow unprivileged bind mounts
On Tue, 8 Jan 2008, Miklos Szeredi wrote:
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
+static int reserve_user_mount(void)
+{
+ int err = 0;
+
+ spin_lock(vfsmount_lock);
+ if (nr_user_mounts = max_user_mounts !capable(CAP_SYS_ADMIN))
+ err = -EPERM;
+ else
+ nr_user_mounts++;
+ spin_unlock(vfsmount_lock);
+ return err;
+}
Would -ENOSPC or -ENOMEM be a more descriptive error here?
The logic behind EPERM, is that this failure is only for unprivileged
callers. ENOMEM is too specifically about OOM. It could be changed
to ENOSPC, ENFILE, EMFILE, or it could remain EPERM. What do others
think?
I think it would be important to log the non-trivial errors. Several
mount(8) hints to check for the reason by dmesg since it's already too
challanging to figure out what's exactly the problem by the errno value.
This could also prevent to mislead troubleshooters with the mount/sysctl
race.
Szaka
--
NTFS-3G: http://ntfs-3g.org
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/6][RFC] Cleanup FIBMAP
On Sat, 27 Oct 2007, Anton Altaparmakov wrote: And another of my pet peeves with -bmap is that it uses 0 to mean sparse which causes a conflict on NTFS at least as block zero is part of the $Boot system file so it is a real, valid block... NTFS uses -1 to denote sparse blocks internally. In practice, the meaning of 0 is file system [driver] dependent. For example in case of NTFS-3G it means that the block is sparse or the file is encrypted or compressed, or resident, or it's the $Boot file, or an error happened. Thankfully the widely used FIBMAP users (swapon and the ever less used lilo) are only interested in the non-zero values and they report an error if the driver returns 0 for some reason. Which is perfectly ok since both swaping and Linux booting would fail using a sparse, encrypted, compressed, resident, or the NTFS $Boot file. But in real, both swap files and lilo work fine with NTFS if the needed files were created the way these softwares expect. If not then swapon or lilo will catch and report the file creation error. Afair, somebody is doing (has done?) an indeed much needed, better alternative. Bmap is legacy, thank you Mike for maintaining it. Szaka -- NTFS-3G Lead Developer: http://ntfs-3g.org - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
