Date: Mon, 6 Oct 2003 18:15:18 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Nate Lawson <nate@root.org> Cc: current@FreeBSD.org Subject: Re: msdosfs mask? Message-ID: <20031006173858.Y8422@gamplex.bde.org> In-Reply-To: <20031005112505.J474@root.org> References: <20031005112505.J474@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 5 Oct 2003, Nate Lawson wrote: > In the past, msdosfs has taken its permissions from the mountpoint. > Recently I noticed that this still works for files in the root directory > but subdirectories are all chmod 000. Has anyone else seen this? Adding > the -m=755 flag for instance does work for the files in the top of the > mountpoint (i.e. command.com) but not subdirectories, which are still 000. > What's going on? This still works for me. Perhaps your mount_msdosfs binary is out of date. Rev.1.25 of mount_msdosfs.c is required to keep up with corresponding kernel changes. It passes a separate mask for directories. Old versions of mount_msdosfs don't understand the new field for the directory mask in the args struct so they don't pass anything. More precisely, it happens that the new field fits in unnamed padding in the old args struct, so adding it didn't completely break binary compatibility with old mount_msdosfs binaries; all version fill memset the struct to 0 so they set unnamed padding to 0, so old versions do the equivalent of the new version when the latter is invoked with "-M 0". But a mask of 0 is rarely what is wanted. The compatibility problems can be fixed easily since the new field is in spare space and there is already a magic number and flags for version control. See also PR bin/57401 which has a quick fix for amd. The fix is wrong since it is under a wrong ifdef, and it shouldn't be necessary -- amd should work like an old mount_msdosfs binary and simply not pass a dirmask (by not setting a flag which that it passes one). amd could also use flags for saying that it doesn't pass a file mask or uid or gid... either. It always passes 0777 for the file mask and 0 for the ids instead of the attributes inherited from the mount point. Perhaps more of the logical for this should be in the kernel since applications get it wrong. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031006173858.Y8422>