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>