Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Nov 2017 22:05:35 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Karl Denninger <karl@denninger.net>
Cc:        "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>
Subject:   Re: MSDOS Filesystem question related to "read-only" files
Message-ID:  <20171121213516.G1948@besplex.bde.org>
In-Reply-To: <f4ccb904-63fd-4641-89c8-09357fbb5a1c@denninger.net>
References:  <f4ccb904-63fd-4641-89c8-09357fbb5a1c@denninger.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Nov 2017, Karl Denninger 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.=C2=A0 It l=
ooks
> like OpenBSD supports this from reading their man pages.

FreeBSD used to support this as a permissions bit, but was changed to suppo=
rt
it as only an attribute (except for a buggy write-only affect on permission=
s)
See r254627 and my reply to the commit mail for r326031.

> FreeBSD doesn't appear to.=C2=A0 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.=C2=A0 Al=
l
> good so far.=C2=A0

r254627 changed it to do this.  This is too simple.

> But attempting to chmod a file to remove write permission
> "succeeds" (returns success) but does nothing.

It actually changes the attribute to ATTR_READONLY, but this is write only
in current versions of FreeBSD.  The change becomes active on reboot to som=
e
other OS's (including FreeBSD before r254627).

r326031 unimproves this by reporting in struct stat that the file is
read-only although it is still writeable.

> Is this capability simply not present on FreeBSD?=C2=A0 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.

Immutable or nounlink flags would work better for this, but are unavailable
for msdosfs.

To prevent removal by rm -rf, there is nothing better than making the
readonly attribute affect the permissions again, but a special application
can handle this better by checking the attributes directly (the available
ones depend on the file systems).

Note that ordinary permissions don't affect root, so you have to be careful
with rm -rf anyway.  Perhaps the readonly attribute should be handled as
an immutable flag.  msdosfs also has a SYSTEM attribute which is even
closer to immutability.  MSDOS and Windows use HIDDEN | READONLY | SYSTEM
for files that it doesn't want anyone to know about -- these are sort of
immutable.  But the SYSTEM attribute is currently treated even more simply
than READONLY.  It is purely write-only in the kernel, except applications
can read it to use it for anything.  It is used mainly by cp(1) to preserve
it.

You could put ffs on the USB stick and use its UF_READONLY as a hint.  It
doesn't affect permissions in ffs, so it doesn't prevent rm -rf, just like
in msdosfs, but a application with special handling of it would work the
same for both.  ffs just doesn't need this because it has immutable flags
that work better.

Bruce
From owner-freebsd-fs@freebsd.org  Tue Nov 21 13:26:08 2017
Return-Path: <owner-freebsd-fs@freebsd.org>
Delivered-To: freebsd-fs@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 334BEDEECE2
 for <freebsd-fs@mailman.ysv.freebsd.org>; Tue, 21 Nov 2017 13:26:08 +0000 (UTC)
 (envelope-from shiva.bhanujan@quorum.com)
Received: from asp.reflexion.net (outbound-mail-210-101.reflexion.net
 [208.70.210.101])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id D3E6B6E8B0
 for <freebsd-fs@freebsd.org>; Tue, 21 Nov 2017 13:26:06 +0000 (UTC)
 (envelope-from shiva.bhanujan@quorum.com)
Received: (qmail 28880 invoked from network); 21 Nov 2017 13:19:20 -0000
Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1)
 by 0 (rfx-qmail) with SMTP; 21 Nov 2017 13:19:20 -0000
Received: by rtc-sm-01.app.dca.reflexion.local
 (Reflexion email security v8.40.3) with SMTP;
 Tue, 21 Nov 2017 08:19:20 -0500 (EST)
Received: (qmail 18451 invoked from network); 21 Nov 2017 13:19:20 -0000
Received: from unknown (HELO mail.quorum.net) (64.74.133.216)
 by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Nov 2017 13:19:20 -0000
Received: from QLEXC01.Quorum.local ([fe80::edb6:63d5:778f:2f0e]) by
 QLEXC01.Quorum.local ([fe80::edb6:63d5:778f:2f0e%14]) with mapi id
 14.03.0351.000; Tue, 21 Nov 2017 05:19:19 -0800
From: Shiva Bhanujan <Shiva.Bhanujan@Quorum.com>
To: Andriy Gapon <avg@FreeBSD.org>, "freebsd-fs@freebsd.org"
 <freebsd-fs@freebsd.org>
Subject: RE: zio_done panic in 10.3
Thread-Topic: zio_done panic in 10.3
Thread-Index: AdNiPrZNqbG0j29/RtqtjwQQWT08KgAsk0+A//+0h/c=
Date: Tue, 21 Nov 2017 13:19:17 +0000
Message-ID: <3A5A10BE32AC9E45B4A22F89FC90EC0701C367D562@QLEXC01.Quorum.local>
References: <3A5A10BE32AC9E45B4A22F89FC90EC0701C367D3D1@QLEXC01.Quorum.local>,
 <5021a016-9193-b626-78cf-54ffa3929e22@FreeBSD.org>
In-Reply-To: <5021a016-9193-b626-78cf-54ffa3929e22@FreeBSD.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.201.188.3]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>;
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 13:26:08 -0000

the vmcore file is =7E4G.  can you please tell me how to deliver this to =
you?



From: Andriy Gapon =5Bavg=40FreeBSD.org=5D
Sent: Tuesday, November 21, 2017 1:49 AM
To: Shiva Bhanujan; freebsd-fs=40freebsd.org
Subject: Re: zio_done panic in 10.3


On 20/11/2017 22:34, Shiva Bhanujan wrote:
> Hello,
>=20
> I'm getting a kernel panic in FreeBSD 10.3 p22 (r324806M).=20
>=20
> KDB: stack backtrace:
> =230 0xffffffff80982fe0 at kdb_backtrace+0x60
> =231 0xffffffff80945cb6 at vpanic+0x126
> =232 0xffffffff80945b83 at panic+0x43
> =233 0xffffffff80d4ac6b at trap_fatal+0x36b
> =234 0xffffffff80d4af6d at trap_pfault+0x2ed
> =235 0xffffffff80d4a5ea at trap+0x47a
> =236 0xffffffff80d305b2 at calltrap+0x8
> =237 0xffffffff8094db5d at _sx_xlock+0x5d
> =238 0xffffffff81a4ccec at zio_done+0x92c
> =239 0xffffffff81a486ea at zio_execute+0x10a
> =2310 0xffffffff80993e15 at taskqueue_run_locked+0xe5
> =2311 0xffffffff809948a8 at taskqueue_thread_loop+0xa8
> =2312 0xffffffff8090f13a at fork_exit+0x9a
> =2313 0xffffffff80d30aee at fork_trampoline+0xe
>=20
> We are doing send/receive of zfs snapshots by piping it through mbuffer =
and netcat. I can't seem to relate send/receive to the above backtrace.
>=20
> The closest bug that I've found w/ a panic close to the above is as =
follows:
>=20
> =
https://bugs.freebsd.org/bugzilla/show_bug.cgi?format=3Dmultiple&id=3D181966
>=20
> I haven't been able to find any commits against this backtrace. Can =
anybody please point me to anything that might have addressed this issue? =
please let me know if there is any additional information that you might =
need.

Do you have a crash dump (vmcore) ?
If not, could you please get one?

--=20
Andriy Gapon





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171121213516.G1948>