From nobody Mon Feb 12 18:41:12 2024 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TYYFq715Zz5BKrp for ; Mon, 12 Feb 2024 18:41:35 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: from wfhigh5-smtp.messagingengine.com (wfhigh5-smtp.messagingengine.com [64.147.123.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TYYFq5Cd7z4h1b; Mon, 12 Feb 2024 18:41:35 +0000 (UTC) (envelope-from chuck@tuffli.net) Authentication-Results: mx1.freebsd.org; none Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfhigh.west.internal (Postfix) with ESMTP id 6279A180012A; Mon, 12 Feb 2024 13:41:34 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute7.internal (MEProxy); Mon, 12 Feb 2024 13:41:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuffli.net; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1707763293; x=1707849693; bh=zGjIqLS4X+ 8npDyHtZFGVyK/mM+un9e5dDy55q9RNmk=; b=HRGRfuJ3/V9KJCJmlGAWYePVOc joBmGrak7dZ/wUOSB4pK0ACMgBOv9X05QjGQa9msTd87qxQUS++Ixint5/P7qROB fZ4rPUgrU6VtmwD5hsLoAR6YEO2JICIsIYmq4v4Ff58Zxroom0FZyvNSMrV895Op zIEGo/R6+79KxYghXSWdcEyVFrXwLrDHvjC/PpVowqCDwfOQBpBXcw1/iuHfmZSM recvF2Ot7Mu4Upu+kxge+tUoAz4NCEjotpEjpLsJ+OCrS7D5tGu38z5MTMbzSne2 IQXEtGrnZw6euDaOzerar7birniz2w2tkILfGNGVKiy25cyDkGSsmQQsqsPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1707763293; x=1707849693; bh=zGjIqLS4X+8npDyHtZFGVyK/mM+u n9e5dDy55q9RNmk=; b=O/HJZGkzFuJ0bRXeLjbuhF2ASCySktaFJx9EhORAoI/P etRy2IL7lgpjGDQFfWVpWGyGTHUifx4jNUBBQWhby5K2a/+hRd03+5t7/DCvV6tv vXik4PPs1ftCJWlsByRsdELp8URg55P4N42LqEtYMlvuVunuTARJzBMLNNkBL+dG 8D05MeMMam/8DerXc4C708VW7hHW91UXSrdnBOrW7UrcSqY3N2COR64rUjNkw95+ tfXBPtBVJNoU45qU2bc2BhXP4TDnM3v+rcD0cFG/0FvOr2H7wvbqehPIaXyqiOLg TvDsgRA8j/eFR0Md2goN3HjiRsilpwdTJqZ3fRuXDg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudefgdduudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfvehh uhgtkhcuvfhufhhflhhifdcuoegthhhutghksehtuhhffhhlihdrnhgvtheqnecuggftrf grthhtvghrnhepteekvdeuleduhffhjefhfefgtefgveeugfekfeeuheffgfeuteegfeff gfekhfdvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eptghhuhgtkhesthhufhhflhhirdhnvght X-ME-Proxy: Feedback-ID: ib6f94606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1D7B8B6008D; Mon, 12 Feb 2024 13:41:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Message-Id: <896c3f19-e758-4e73-aab2-3a69a9534d82@app.fastmail.com> In-Reply-To: References: Date: Mon, 12 Feb 2024 10:41:12 -0800 From: "Chuck Tuffli" To: "Brooks Davis" Cc: fs@freebsd.org Subject: Re: when is VFCF_JAIL allowed? Content-Type: multipart/alternative; boundary=413d905ccb8242d6910974240aea6fac X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US] X-Rspamd-Queue-Id: 4TYYFq5Cd7z4h1b X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated --413d905ccb8242d6910974240aea6fac Content-Type: text/plain On Mon, Feb 12, 2024, at 10:16 AM, Brooks Davis wrote: > On Mon, Feb 12, 2024 at 10:02:01AM -0800, Chuck Tuffli wrote: > > I was experimenting with a workflow and needed to allow a jail to mount an ISO image. This fails because the cd9660 file system does not set VFCF_JAIL: > > can be mounted from within a jail if allow.mount and > > allow.mount. jail parameters are set > > Is there a reason jails should not be allowed to mount an ISO or is it because no one has added the support? > > File systems where the kernel parses a binary disk image aren't generally > safe because a bad image can corrupt kernel state. It should be safe > and allowed to mount an ISO via fusefs (not sure if we have a module > available in ports, but I'd guess so.) Thanks for the feedback, Brooks. This makes sense, but I must be missing the safety difference between host and the jail. On the host, I can do: # mdconfig -a -t vnode -f ./seed.iso -u 1 # mount_cd9660 /dev/iso9660/cidata /media/ Does this not run the same risk of corrupting kernel state, or maybe this is a bug? I'm also noticing the msdosfs cannot be mounted in a jail either: $ lsvfs cd9660 msdosfs Filesystem Num Refs Flags -------------------------------- ---------- ----- --------------- cd9660 0x000000bd 0 read-only msdosfs 0x00000032 1 Is there a similar issue with this file system as well? --chuck --413d905ccb8242d6910974240aea6fac Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, Feb 12,= 2024, at 10:16 AM, Brooks Davis wrote:
On Mon, Feb 12, 2024 at 10:02:01AM -0800, C= huck Tuffli wrote:
> I was experimenting with a workflo= w and needed to allow a jail to mount an ISO image. This fails because t= he cd9660 file system does not set VFCF_JAIL:
> &n= bsp;           &n= bsp;         can be mounted from= within a jail if allow.mount and
>   &n= bsp;           &n= bsp;       allow.mount.<vfc_name> ja= il parameters are set
> Is there a reason jails should = not be allowed to mount an ISO or is it because no one has added the sup= port?

File systems where the kernel parses = a binary disk image aren't generally
safe because a bad im= age can corrupt kernel state.  It should be safe
and = allowed to mount an ISO via fusefs (not sure if we have a module
available in ports, but I'd guess so.)
Thanks for the feedback, Brooks. This makes sense, but I must be missin= g the safety difference between host and the jail. On the host, I can do= :

# mdconfig -a -t vnode -f ./seed.iso -u 1=
# mount_cd9660 /dev/iso9660/cidata /media/
=
Does this not run the same risk of corrupting kernel stat= e, or maybe this is a bug?

I'm also noticin= g the msdosfs cannot be mounted in a jail either:

$ lsvfs cd9660 msdosfs
Filesystem   =             =             =    Num  Refs  Flags
------------------= -------------- ---------- -----  ---------------
cd96= 60           &nbs= p;           &nbs= p;   0x000000bd     0  read-only
<= /div>
msdosfs         &= nbsp;           &= nbsp;    0x00000032     1

Is there a similar issue with this file system as well= ?

--chuck
--413d905ccb8242d6910974240aea6fac--