MSDOS Filesystem question related to "read-only" files

[Karl Denninger]

Oh, here's another interesting anomaly -- MSDOS filesystems return "0"
for the free file count!

(gdb) print fsbuf
$3 = {f_version = 537068824, f_type = 50, f_flags = 4096, f_bsize = 4096,
  f_iosize = 4096, f_blocks = 1949442, f_bfree = 1949436, f_bavail =
1949436,
  f_files = 0, f_ffree = 0, f_syncwrites = 3, f_asyncwrites = 5,
  f_syncreads = 1907, f_asyncreads = 0, f_spare = 0xbf3fd628, f_namemax
= 255,
  f_owner = 0, f_fsid = {val = 0xbf3fd680}, f_charspare = 0xbf3fd688 "",
  f_fstypename = 0xbf3fd6d8 "msdosfs",
  f_mntfromname = 0xbf3fd6e8 "/dev/da0s1", f_mntonname = 0xbf3fd740 "/mnt"}

Needless to say that can cause some interesting issues if you're coding
to avoid potential inode exhaustion and the target is a MSDOS
filesystem..... FAT filesystems DO have a maximum file count, incidentally.

On 11/20/2017 14:08, Karl Denninger wrote:
> Oh, my apologies -- I didn't include the version:
>
> FreeBSD 11.0-STABLE #0 r313159M: Fri Feb  3 09:58:35 CST 2017
>
> On an RPI2, but I doubt that matters.
>
>
> On 11/20/2017 14:02, Karl Denninger wrote:
>> root at Test-MCP:/home/karl/HD-MCP # cd /mnt
>> root at Test-MCP:/mnt # mount
>> /dev/ufs/rootfs on / (ufs, local, noatime, soft-updates, nfsv4acls)
>> devfs on /dev (devfs, local)
>> tmpfs on /tmp (tmpfs, local)
>> /dev/da0s1 on /mnt (msdosfs, local)
>> root at Test-MCP:/mnt # ls -al
>> total 408
>> drwxr-xr-x   1 hdmcp  wheel    4096 Jan  1  1980 .
>> drwxr-xr-x  20 root   wheel     512 Nov 20 16:04 ..
>> drwxr-xr-x   1 hdmcp  wheel    4096 Nov 19 11:20 System Volume Information
>> -rwxr-xr-x   1 hdmcp  wheel  127979 Nov 19 22:54
>> cam2-2017-11-19-22-54-47.jpg
>> -rwxr-xr-x   1 hdmcp  wheel  271295 Nov 19 22:57
>> cam2-2017-11-19-22-57-20.jpg
>> root at Test-MCP:/mnt # chmod u-w *
>> root at Test-MCP:/mnt # ls -al
>> total 408
>> drwxr-xr-x   1 hdmcp  wheel    4096 Jan  1  1980 .
>> drwxr-xr-x  20 root   wheel     512 Nov 20 16:04 ..
>> drwxr-xr-x   1 hdmcp  wheel    4096 Nov 19 11:20 System Volume Information
>> -rwxr-xr-x   1 hdmcp  wheel  127979 Nov 19 22:54
>> cam2-2017-11-19-22-54-47.jpg
>> -rwxr-xr-x   1 hdmcp  wheel  271295 Nov 19 22:57
>> cam2-2017-11-19-22-57-20.jpg
>> root at Test-MCP:/mnt #
>>
>> Nope.  The "w" is still there.
>>
>> No error returned from the "chmod" command (or if I call it from a C
>> program) but the file mode is NOT changed whether I'm doing it as the
>> superuser or as the owner of the file (and directory)
>>
>> On 11/20/2017 12:30, Conrad Meyer wrote:
>>> Hi Karl,
>>>
>>> In fact, msdosfs in FreeBSD should set the FAT READONLY attribute
>>> under two conditions:
>>>
>>> 1. The owner chmod's the file non-writeable (chmod u-w) (what you've
>>> described, I think).  Or,
>>> 2. The super user or otherwise privileged user sets the "readonly"
>>> flag on the file via chflags(1).
>>>
>>> How have you determined that chmod u-w does nothing?  What version of
>>> FreeBSD are you using?
>>>
>>> Best,
>>> Conrad
>>>
>>>
>>> On Mon, Nov 20, 2017 at 7:36 AM, Karl Denninger <karl at denninger.net> wrote:
>>>> I'm running into an interesting issue here and wondering if there's a
>>>> way to do this under FreeBSD.
>>>>
>>>> MSDOS filesystems have a "primitive" permission capability;
>>>> specifically, they can have a "Read-only" attribute on a file.  It looks
>>>> like OpenBSD supports this from reading their man pages.
>>>>
>>>> FreeBSD doesn't appear to.  When you mount a msdos filesystem (e.g. a
>>>> USB stick) whoever owns the parent directory where you mount it gives
>>>> you the permissions and "ownership" of files on said filesystem.  All
>>>> good so far.  But attempting to chmod a file to remove write permission
>>>> "succeeds" (returns success) but does nothing.
>>>>
>>>> Is this capability simply not present on FreeBSD?  I'm interested in
>>>> using it as a means of "flagging" files on a USB stick in an application
>>>> that I do not want to remove if the stick fills (basically, to "protect"
>>>> them from being aged off) and it appears there's no way to do it, other
>>>> than to use something unique in the filename that I would then have to
>>>> pay attention to.
>>>>
>>>> --
>>>> Karl Denninger
>>>> karl at denninger.net <mailto:karl at denninger.net>
>>>> /The Market Ticker/
>>>> /[S/MIME encrypted email preferred]/

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20171120/0e67bad7/attachment.bin>