From nobody Thu Nov 28 19:55:07 2024 X-Original-To: freebsd-current@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 4Xzn944ff2z5fBRG for ; Thu, 28 Nov 2024 19:55:20 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xzn942j8Jz4pHs for ; Thu, 28 Nov 2024 19:55:20 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5d071f70b51so1388762a12.3 for ; Thu, 28 Nov 2024 11:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732823718; x=1733428518; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=n1yTVFIuvOJbiqVHghLBZ9rLoLkclQneWIpIczwlhbI=; b=M/TmFcxZct+seFjrMOfSEfh7Zs2zPwMVVaazMMFhZ35otcSWCHpsf4noffoCL3Dvwa j+3x4II4lTjsmkkSwmia2oEpmsP2fnCDkZPpsFqM7qhwDtrr39AvOIZ9YNEpAppTKf8K xENsEQFvCdk+fIpDAF9zqH02ysUfY7oNiDrfn1e2RXf5u5txPJYXY/Fk2K9wL86gap4s +k4aL90jsX2+QcLXdjg5mtvApRe9HX1+LiB//XvyBZ8e+Hnvy1v+4FvYdfoFsnZJadEW BIuS38B/yTYnd/qjKlm1rwQ+7lh0bK0saZCrCHsTzZ+lqHqjC38lK5v6TA6cBGM7TTkg 51gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732823718; x=1733428518; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=n1yTVFIuvOJbiqVHghLBZ9rLoLkclQneWIpIczwlhbI=; b=SzaRpwGyQacD1NuqQaYe29PbS9tbfnIGPPRZWaJQvyNPfWFwtc2PyRsug7w8SgKvcg yJVryikops08NrFGjZdp/p0XGpQDzGaJBZYwS6YRsWQqxgX9vAPnsYedggOwLKp4EhtU NhNfblPl1p5LkH4myJODndYThkg6QgulG7sOkt94umHn5iB3VJOsi0Y0zrrGCuZdIR4h /NpD1+z89mIkXnz2NPEAwFAfkqGvZSWaE344XttnZrNPOrU9rjdWgOc5Wq4tvfa+/yEW mGtXVRNSx77nz3Oyj7IFLQFydVP6+ko82BMYvFP41vbzpCcsUdFlyNT5sclOx3sSqdPT n6Fw== X-Gm-Message-State: AOJu0YywBbPyylCHxE3/BbXa1AYKQIfZghpUoNrOIi3FFaP1BsqPzp8R rZMxgfLlpTVLCM5Y1EQlZ4JyWzgpru5bpjUIt6XVMaoK063W8oYlmQlakXz9lF/bF+Tl5itUw8s ncom8OUVo/L2ATKAEJiA7Ahv8UA== X-Gm-Gg: ASbGnctOpOVLhIDBsyxHLTydccctYp9+h6VpxIMUGmcqmXP2xH/XFRUbJ8gO4jvTacR Uk+TAacfR0Z/H/arjmWQGf2UZKIbX8z9curnM+L3MWjgqk4NX7SHY4vtRCoACBlU= X-Google-Smtp-Source: AGHT+IG3g8pVkBvjim6Q5WvY12sSCi3Ce+/cWgZM3MM5MZW4BVM7+v/k1tuOG0kiHI0gt1fuP1o60Npkpn7Ar8HW5zU= X-Received: by 2002:a05:6402:354f:b0:5cf:f42f:de82 with SMTP id 4fb4d7f45d1cf-5d080b8c885mr7730606a12.7.1732823717387; Thu, 28 Nov 2024 11:55:17 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <4FEA762C-5E0F-4D3F-82D9-DF93CF1BC1F5@gid.co.uk> In-Reply-To: <4FEA762C-5E0F-4D3F-82D9-DF93CF1BC1F5@gid.co.uk> From: Rick Macklem Date: Thu, 28 Nov 2024 11:55:07 -0800 Message-ID: Subject: Re: RFC: fixing PR#282995 To: rb@gid.co.uk Cc: FreeBSD CURRENT , Michael Proto Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Xzn942j8Jz4pHs X-Spamd-Bar: ---- On Thu, Nov 28, 2024 at 7:49=E2=80=AFAM wrote: > > > > > On 28 Nov 2024, at 15:04, Rick Macklem wrote: > > > > On Thu, Nov 28, 2024 at 4:36=E2=80=AFAM Bob Bishop wrote= : > >> > >> Hi, > >> > >>> On 27 Nov 2024, at 21:56, Rick Macklem wrote= : > >>> > >>> Hi, > >>> > >>> PR#282995 reports that the "-alldirs" export option is broken, > >>> since it allows an export where the directory path is not a mount poi= nt. > >>> > >>> I'll admit I did not recall this semantic for -alldirs and I now see = it is only > >>> documented in the "Examples" section of exports(5). > >>> > >>> Looking at the code, it appears this was broken between releng1 and > >>> releng2.0 (about 30years ago) when the call to mount(2) in mountd.c > >>> was changed from using the path in the exports line to using f_mntonn= ame. > >>> (The check for "it is a mount point" depended on mount(2) failing bec= ause > >>> the path was not a mount point.) > >>> > >>> I do believe the semantic is a useful one, > >> > >> Why? > > Suppose /cdrom is where a CD is mounted sometimes. > > If this is exported when the CD is not mounted, it will export > > the "/" file system. > > --> This export is probably not what the sysadmin wanted. > > mountd does now generate a warning about this, which > > was how the exporter spotted the bug. > > For example (the line in /etc/exports): > > /cdrom -alldirs > > will export "/" to "the world" if /cdrom is not mounted. > > I will agree that is undesirable. > > > The example in the exports(5) man page claims the export > > line will fail, so "/" would not be exported. This seems like > > a better semantic to me. > > It=E2=80=99s certainly safer but will cause client mounts to fail as well= . It would be nicer to export an empty directory. A couple of comments here (mostly for everyone else reading this). 1 - From a security point of view, exports apply to server file systems, not directories. (They are stored in the kernel on file system mount points.) 2 - The "administrative controls" which allow mounts for only certain directories within a server file system is not a significant security tool. They can be easily circumvented and only work for NFSv3 and not NFSv4, since they only affect the NFSv3 sideband Mount protocol. 3 - The whole purpose of exports(5) is to make undesirable NFS client mounts fail. Personally, I wish these "administrative controls" did not exist. They were created way back in the mid-1980s so that BSD (CSRG) could be "Sun compatible". When I got involved in NFS on FreeBSD I tried to convince the "collective" to get rid of them, but there was pushback, due to that being a POLA violation. --> As such, they still exist. They still cause confusion w.r.t. what is exported and I, personally, recommend they be avoided when a exports(5) file is created in order to minimize the risk of exporting some file system that is undesirable from a security perspective. rick ps: Thanks for the comments. I am proceeding with (C). > > > rick > > > >> > >>> although making it that way > >>> after 30years might be construed as a POLA violation? > >>> > >>> So, what do others think I should do with this? > >>> (A) - Patch mountd to enforce the "must be a mount point when -alldir= s > >>> is specified, plus update exports(5) to state this semantic cle= arly. > >>> or > >>> (B) - Patch mountd so that it enforces "must be a mount point when -a= lldirs > >>> is specified, but only enabled via a new mountd command line op= tion. > >>> --> ie. Leave the default as not enforced, but allow enforcemen= t based > >>> on a new mountd option. > >>> - Document this in both exports(5) and mountd(8). > >>> or > >>> ??? > >> > >> (C) - Patch mountd so that it enforces "must be a mount point when -al= ldirs > >> is specified, but provide a new mountd command line option to re= store the old behaviour. > >> --> ie. Default as enforced, but allow an override based on a n= ew mountd option. > >> - Document this in both exports(5) and mountd(8). > >> > >> I think that (A) is too POLA-unfriendly. > >> > >>> Thanks in advance for your comments, rick > >>> > >> > >> -- > >> Bob Bishop > >> rb@gid.co.uk > >> > >> > >> > >> > > > > -- > Bob Bishop > rb@gid.co.uk > > > >