On Mon, 19 May 2008, Alon Bar-Lev wrote:
> On Monday 19 May 2008, Szabolcs Szakacsits wrote:
> >
> > I really would like to but /sbin is also hard coded (security reason) in
> > the mount utlities to make mounts work.
> >
> > This is from mount.c (util-linux, util-linux-ng, etc):
> >
> > sprintf(mountprog, "/sbin/mount.%s", type);
> > if (stat(mountprog, &statbuf) == 0) {
> > ...
> > execv(mountprog, mountargs);
> >
>
> I am aware of this.
> But it is the packager job to place files in the correct distribution
> location.
I'm all for it.
> Placing ntfs-3g at root is not always required, as many users don't
> actually boot from this filesystem.
It's not always required (it depends on /etc/fstab, partitioning, etc) but
it's strongly recommended for a packager, otherwise some users may not be
able to mount NTFS during boot. They don't need to boot from NTFS or use
NTFS as /usr for this to happen.
Here is an /etc/fstab example where mounting NTFS will fail if an ntfs-3g
component (binary, library, external fuse library) isn't installed on the
root partition:
/dev/hda2 / ext3 defaults 1 1
/dev/hda1 /mnt/windows ntfs-3g defaults 0 0
/dev/hda3 /usr ext3 defaults 0 0
If the two last lines are exchanged or the user uses the in-kernel NTFS
driver then automount works. Usually this is very frustrating and hard to
figure out even for knowledgable users.
Both users and configuration tools regularly edit /etc/fstab "incorrectly"
which results random boot time automount failures.
The above example is the simplest failure scenario. There are very subtle
ones. Unfortunately I debugged too many of them.
> > ntfs-3g is just like smbfs, ncpfs, cifs, etc. If /sbin/mount.ntfs-3g
> > doesn't exist then 'mount -t ntfs-3g ...' and mount via /etc/fstab is
> > guaranteed to fail on Linux. Mount(8) doesn't use the PATH variable
> > (security reason), it only looks for the mount helpers in /sbin,
> > nowhere else.
>
> The default of cifs in my Gentoo machine is:
>
> /sbin
> /sbin/mount.cifs -> /usr/bin/mount.cifs
> /usr
> /usr/bin
> /usr/bin/mount.cifs
> /usr/bin/umount.cifs
>
> Notice that the binaries are located in /usr...
Network file systems typically are mounted after the local block devices
are mounted, so they are available and can't fail. This is not guaranteed
for ntfs-3g.
> The convention is to place all files under $prefix and if user want
> to override it can do this using --with-something.
I think widely used, block device based file systems in user space are not
too conventional. There are assumptions that they are in the kernel. If
these assumptions aren't fulfilled then they can fail.
What Miklos Szeredi did with FUSE is a miracle.
> > We could have an option to disable the creation of /sbin/mount.ntfs-3g.
> > Creating it anywhere else is no use for anything and always makes mount(8)
> > to fail. If user disables it then he acknowledges that mount(8) and
> > /etc/fstab will not work with ntfs-3g.
>
> There is a minor issue of chroot installation, and cross compile...
We could disable the creation of /sbin/mount.ntfs-3g by a new
--disable-mount-helper option, similarly to --disable-ldconfig.
--disable-mount-helper could be the default on all OSes except Linux.
This would solve Eric's problem too. How does it sound?
Regards,
Szaka
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
