From owner-freebsd-arch@freebsd.org Thu May 14 18:27:00 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3579D2DA023 for ; Thu, 14 May 2020 18:27:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NKkr0cBSz4g3h for ; Thu, 14 May 2020 18:27:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 04591103CB for ; Thu, 14 May 2020 18:27:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f179.google.com with SMTP id 190so4035721qki.1 for ; Thu, 14 May 2020 11:26:59 -0700 (PDT) X-Gm-Message-State: AOAM533nj1v1sagNNXZ/80ipdlUBjk1DFezo+ZmpHkugx52LHDD8iMii ZEBl1apSfjhTXpxlPSdErxEp3nwLEmZOcjH/j4A= X-Google-Smtp-Source: ABdhPJzuBnThbSnMm0LpeJSv66ATX7wZRQwIXyRnaEWkIxEVC917DIJVP/nM4tAL5UWrsx/FeqCce95RchbMm//tNeM= X-Received: by 2002:a37:2711:: with SMTP id n17mr6247635qkn.430.1589480819498; Thu, 14 May 2020 11:26:59 -0700 (PDT) MIME-Version: 1.0 From: Kyle Evans Date: Thu, 14 May 2020 13:26:46 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: [HEADSUP] Disallowing read() of a directory fd To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 18:27:00 -0000 Hi, This is a heads up, given that I'm completely flipping our historical behavior- I intend to commit this review in a couple days' time without substantial objection: https://reviews.freebsd.org/D24596 With this, FreeBSD 13 will not allow read() of a directory fd, which could have previously returned some data from the underlying filesystem in no particular standardized format. This is a still-standards-compliant switch from one implementation-defined behavior to another that's already been adopted in various other popular kernels, to include OpenBSD, MacOS, and Linux. Worth noting is that there's not really one largely-compelling reasons to switch this after so many years (unless you find yourself that irate when you accidentally `cat` a directory), but there are some benefits which are briefly discussed in the commentary around the review along with the history of the current behavior. This change also simplifies filesystem implementations to some extent. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Thu May 14 18:47:24 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 949DB2DA7E9 for ; Thu, 14 May 2020 18:47:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49NLBM0WG2z3Cg5; Thu, 14 May 2020 18:47:22 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 3694B1AF18C; Thu, 14 May 2020 18:47:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id 04EIlEWW032677 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 18:47:14 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id 04EIlEGG032676; Thu, 14 May 2020 18:47:14 GMT (envelope-from phk) To: Kyle Evans cc: "freebsd-arch@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32674.1589482034.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Thu, 14 May 2020 18:47:14 +0000 Message-ID: <32675.1589482034@critter.freebsd.dk> X-Rspamd-Queue-Id: 49NLBM0WG2z3Cg5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.59 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.64)[-0.640,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.04)[ip: (0.06), ipnet: 130.225.0.0/16(0.08), asn: 1835(0.08), country: EU(-0.01)]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 18:47:24 -0000 -------- In message >This is a heads up, given that I'm completely flipping our historical >behavior- I intend to commit this review in a couple days' time >without substantial objection: https://reviews.freebsd.org/D24596 When we did UFS2, I tried to persuade Kirk and Robert that since directories had the 'x' bit set anyway, they start with a magic sequence of: 0x23 0x21 0x2f 0x62 0x69 0x6e 0x2f 0x6c 0x73 0x20 0x2d 0x6c 0x0a = As you can probably guess, they nixed my idea, and now you're making it impossible for ever :-( -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Thu May 14 19:54:18 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6599B2DCE57 for ; Thu, 14 May 2020 19:54:18 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NMgX4k0tz3KjG; Thu, 14 May 2020 19:54:16 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id ZJvpjIishng7KZJvqjah99; Thu, 14 May 2020 13:54:14 -0600 X-Authority-Analysis: v=2.3 cv=ecemg4MH c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=5GkhZBjUJW5Hvhm9WlMA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id D322615C; Thu, 14 May 2020 12:54:12 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 04EJsCma036250; Thu, 14 May 2020 12:54:12 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 04EJsCtH036247; Thu, 14 May 2020 12:54:12 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202005141954.04EJsCtH036247@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Kyle Evans cc: "freebsd-arch@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: References: Comments: In-reply-to Kyle Evans message dated "Thu, 14 May 2020 13:26:46 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 May 2020 12:54:12 -0700 X-CMAE-Envelope: MS4wfK4DnFEuF5TGkeGJUXtlXa4TeQ8KMHzd5ovVcGB5ES+5BKLw4pNxXWzbQxbaY0fUm6TwwcDiphx9BTN8q9Y4bbU8/C9Y0aY1DGLUEfNN/jv7nXZocYwq ZcZw7yXdeokUVKFRr81yDewbgvKd8Q+/QezYZCWwUuWmF6AFK7H+8MfRpcV/rRHJUDSEgRCGFjDPXSmJIPSqADoJh0OQVzW+CGU= X-Rspamd-Queue-Id: 49NMgX4k0tz3KjG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.12) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.25 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RWL_MAILSPIKE_GOOD(0.00)[12.134.59.64.rep.mailspike.net : 127.0.0.18]; REPLYTO_EQ_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; IP_SCORE(-2.55)[ip: (-6.77), ipnet: 64.59.128.0/20(-3.30), asn: 6327(-2.58), country: CA(-0.09)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[12.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 19:54:18 -0000 In message , Kyle Evans writes: > Hi, > > This is a heads up, given that I'm completely flipping our historical > behavior- I intend to commit this review in a couple days' time > without substantial objection: https://reviews.freebsd.org/D24596 > > With this, FreeBSD 13 will not allow read() of a directory fd, which > could have previously returned some data from the underlying > filesystem in no particular standardized format. > > This is a still-standards-compliant switch from one > implementation-defined behavior to another that's already been adopted > in various other popular kernels, to include OpenBSD, MacOS, and > Linux. > > Worth noting is that there's not really one largely-compelling reasons > to switch this after so many years (unless you find yourself that > irate when you accidentally `cat` a directory), but there are some > benefits which are briefly discussed in the commentary around the > review along with the history of the current behavior. > > This change also simplifies filesystem implementations to some extent. OpenBSD has done this for a while and more importantly Linux. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Thu May 14 20:17:21 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A6A472DDBC3; Thu, 14 May 2020 20:17:21 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NNB73y3pz3MfK; Thu, 14 May 2020 20:17:18 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5ddb7209.dip0.t-ipconnect.de [93.219.114.9]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04EKHBXi052956 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2020 22:17:15 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04EKHAnD091168; Thu, 14 May 2020 22:17:11 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04EKH0aA093503; Thu, 14 May 2020 22:17:10 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005142017.04EKH0aA093503@fire.js.berklix.net> To: Kyle Evans cc: "freebsd-arch@freebsd.org" , hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Thu, 14 May 2020 13:26:46 -0500." Date: Thu, 14 May 2020 22:17:00 +0200 X-Rspamd-Queue-Id: 49NNB73y3pz3MfK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.16 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; NEURAL_SPAM_LONG(0.01)[0.011,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_MEDIUM(-0.75)[-0.750,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[9.114.219.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:17:21 -0000 Kyle Evans wrote: > Hi, > > This is a heads up, given that I'm completely flipping our historical > behavior- I intend to commit this review in a couple days' time > without substantial objection: https://reviews.freebsd.org/D24596 > > With this, FreeBSD 13 will not allow read() of a directory fd, which > could have previously returned some data from the underlying > filesystem in no particular standardized format. > > This is a still-standards-compliant switch from one > implementation-defined behavior to another that's already been adopted > in various other popular kernels, to include OpenBSD, MacOS, and > Linux. > > Worth noting is that there's not really one largely-compelling reasons > to switch this after so many years (unless you find yourself that > irate when you accidentally `cat` a directory), but there are some > benefits which are briefly discussed in the commentary around the > review along with the history of the current behavior. > > This change also simplifies filesystem implementations to some extent. > > Thanks, > > Kyle Evans There is ZERO need for a spurious change at 2 days notice after 42+ years ! "cat ." as been supported since Unix V6 1978 or earlier, no problem, even occasionaly useful. Most FreeBSD users wont have heard of https://reviews.freebsd.org/D24596 (& there's only 5 other people's opinions there, apart from proposer, & skimming through the impression is far from un-qualified approval. kevans@ issued arch@ just a couple days notice of intention to commit. arch@ is also not widely read, ( I jhs@ added CC hackers@) Many FreeBSD end users won't even be reading hackers@ (some not even announce@,) & would notice just yet another pointless change sometime after upgrade. Do not force all FreeBSD users towards gratuitous change for personal preference for Linux behaviour. Switch to Linux, Or hack a personalised shell on BSD that does what you want when you type "cat ." If it's later widely popular, use it as proof to re-propose. No Rush. A bigger issue is due notice procedure, & respect to FreeBSD stability of code & users expectations of predictability. Unwarned playing about would detract from FreeBSD's business image. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-arch@freebsd.org Thu May 14 20:20:59 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 642382DE0E5; Thu, 14 May 2020 20:20:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oo1-f68.google.com (mail-oo1-f68.google.com [209.85.161.68]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NNGL2h3hz3NBC; Thu, 14 May 2020 20:20:58 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oo1-f68.google.com with SMTP id i9so1015434ool.5; Thu, 14 May 2020 13:20:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XATE2oJ0HCuFXl80aMe5Q5Rja4dYj+iHGk3WbqQ5L5k=; b=OckIhjHn8hBzYYAVjFfYj2zlSWONwsdA1bjqyew2cfzDgvp2EDEp+FUCHr0PhqHGAc en6/1W9sIQJ33sUd4IG3dFD6k1VWFU2xRmM5Ac5QPKxNlHMZv18Oiq9qJqM7zOMjcftw GcW/knHtMuYVfYm7jKYxQUCMaxqqty+tbo3U0jeWuSTl09LdnbAyxtEAq45dVVuAwzQD ftbNu9HeZAMCn4lA3PuyVDRmwgmId26BSVObsnIFepyDHkHqSViB0UoWZI6nppSMiuhS xJxZylIsMvJEo3qdPIZeRHWGBKo8Kh6mu+wE+73x7avzumTPR5iNQ0M959Yz0BYO8rCL IVpA== X-Gm-Message-State: AOAM531kWZYQPs+cBxLuVLjXdEocpAH7qKE0HGCTjR1xCjt5OaBEjWaE AfmULX0+06qipATAn5RsdY//kuRS49mjlBu3uIYV1+p0 X-Google-Smtp-Source: ABdhPJz1oesoJ2TL0mvKnDzjdg2rT79hMVCT4EGOe2ig/T0QTHbmsRLXhCsYR6R04mPt9AarDhQxnYThlENR1O1X4io= X-Received: by 2002:a4a:3107:: with SMTP id k7mr5037283ooa.61.1589487657049; Thu, 14 May 2020 13:20:57 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> From: Alan Somers Date: Thu, 14 May 2020 14:20:45 -0600 Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: Kyle Evans , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 49NNGL2h3hz3NBC X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.161.68 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-0.89 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-0.95)[-0.947,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.67)[-0.670,0]; TO_DN_SOME(0.00)[]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[68.161.85.209.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_GOOD(0.00)[68.161.85.209.rep.mailspike.net : 127.0.0.18]; IP_SCORE(-0.28)[ip: (-0.51), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.42), country: US(-0.05)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:20:59 -0000 On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: > Kyle Evans wrote: > > Hi, > > > > This is a heads up, given that I'm completely flipping our historical > > behavior- I intend to commit this review in a couple days' time > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > could have previously returned some data from the underlying > > filesystem in no particular standardized format. > > > > This is a still-standards-compliant switch from one > > implementation-defined behavior to another that's already been adopted > > in various other popular kernels, to include OpenBSD, MacOS, and > > Linux. > > > > Worth noting is that there's not really one largely-compelling reasons > > to switch this after so many years (unless you find yourself that > > irate when you accidentally `cat` a directory), but there are some > > benefits which are briefly discussed in the commentary around the > > review along with the history of the current behavior. > > > > This change also simplifies filesystem implementations to some extent. > > > > Thanks, > > > > Kyle Evans > > There is ZERO need for a spurious change at 2 days notice after 42+ years ! > > "cat ." as been supported since Unix V6 1978 or earlier, > no problem, even occasionaly useful. > Really? When is that occasionally useful? I've never seen anything useful come out of reading a directory. From owner-freebsd-arch@freebsd.org Thu May 14 20:28:40 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6CA952DE69E for ; Thu, 14 May 2020 20:28:40 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 49NNRC3wGBz3NvW; Thu, 14 May 2020 20:28:39 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id D03633C0199; Thu, 14 May 2020 20:28:37 +0000 (UTC) Date: Thu, 14 May 2020 20:28:37 +0000 From: Brooks Davis To: Kyle Evans Cc: "freebsd-arch@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200514202837.GD60902@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GpGaEY17fSl8rd50" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 49NNRC3wGBz3NvW X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-6.53 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; IP_SCORE(-3.63)[ip: (-9.56), ipnet: 199.48.128.0/22(-4.77), asn: 36236(-3.79), country: US(-0.05)]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:28:40 -0000 --GpGaEY17fSl8rd50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 14, 2020 at 01:26:46PM -0500, Kyle Evans wrote: > Hi, >=20 > This is a heads up, given that I'm completely flipping our historical > behavior- I intend to commit this review in a couple days' time > without substantial objection: https://reviews.freebsd.org/D24596 >=20 > With this, FreeBSD 13 will not allow read() of a directory fd, which > could have previously returned some data from the underlying > filesystem in no particular standardized format. >=20 > This is a still-standards-compliant switch from one > implementation-defined behavior to another that's already been adopted > in various other popular kernels, to include OpenBSD, MacOS, and > Linux. >=20 > Worth noting is that there's not really one largely-compelling reasons > to switch this after so many years (unless you find yourself that > irate when you accidentally `cat` a directory), but there are some > benefits which are briefly discussed in the commentary around the > review along with the history of the current behavior. >=20 > This change also simplifies filesystem implementations to some extent. I'm sure this made sense in v7, but I've never opened a directory with vi or cat and thought "that's what I wanted to do". In theory can use it as a terrible ls I've you've totally foobar'd your system, but we have /rescue these days. -- Brooks --GpGaEY17fSl8rd50 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJevan1AAoJEKzQXbSebgfAunsIAJC2zN3PESn0dHZPpzSQ3sTE 9V2qKuFYi4IRn9bGoq8VOsumcJFQs0zPawS9iPhHqgoBuZEyu9Gn/p3KHA4/1/Yu 90Mc/qxlMzipovPDh5hQ0PKFzfNhyXCoZnxXnpdsLiwbioAMxfnzEQfoLzYY33ri NgY9PgWx7mhcq9qh9s1b/98RYspND6XzBiYuiY9fAT2HSRf1mWGi8ooANvunES2s k5aPX5IrbVSQRQ34TzQ6LZjqd7ju0gKBaTYwH1NHS7j/8BllomvIldJbgZdOf/2p 6sH0usPfRwZLLVuoTPFkSSgRbCf5zQgW6ykkJwxVyJngJ6Rbp/RXnLcylPOku6M= =jkmr -----END PGP SIGNATURE----- --GpGaEY17fSl8rd50-- From owner-freebsd-arch@freebsd.org Thu May 14 20:30:30 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B6B92DE806; Thu, 14 May 2020 20:30:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49NNTL38M2z3P2V; Thu, 14 May 2020 20:30:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id A1E181AF18C; Thu, 14 May 2020 20:30:27 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id 04EKURnS033551 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 20:30:27 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id 04EKUQmj033550; Thu, 14 May 2020 20:30:26 GMT (envelope-from phk) To: Alan Somers cc: "Julian H. Stacey" , Kyle Evans , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: From: "Poul-Henning Kamp" References: <202005142017.04EKH0aA093503@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33548.1589488226.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Thu, 14 May 2020 20:30:26 +0000 Message-ID: <33549.1589488226@critter.freebsd.dk> X-Rspamd-Queue-Id: 49NNTL38M2z3P2V X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.96 / 15.00]; NEURAL_HAM_MEDIUM(-0.96)[-0.964,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:30:30 -0000 -------- In message , Alan Somers writes: >Really? When is that occasionally useful? I've never seen anything usef= ul >come out of reading a directory. Two things I have done over the years: Figure out which filenames prevent a enormous but sparse directory from being compacted. Figure out which control characters were in a filename. It might be a good idea to add a override flag on this feature, along the lines of: kern.geom.debugflags=3D0x10 -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Thu May 14 22:50:03 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 20C932E2CA7; Thu, 14 May 2020 22:50:03 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NRZL75pJz43RH; Thu, 14 May 2020 22:50:02 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id E32DC122E6; Thu, 14 May 2020 22:50:02 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f174.google.com with SMTP id f83so603000qke.13; Thu, 14 May 2020 15:50:02 -0700 (PDT) X-Gm-Message-State: AOAM533hUdXNWDW6onAueCqLQLy1iLjAFHyZbi1vhKaOMFniPLnejoWB AVHoj/3Irci87fZGWgjXyO3lBNWbeW7g44y2sh8= X-Google-Smtp-Source: ABdhPJyfSUheNEGsNaaPEaIpnrpg2PedS3yTVInniLBJCIqGkIoYi/UZLHkGPyp5Imu2ahHT/06wpYmDW0oAHlGwNjA= X-Received: by 2002:a37:5b47:: with SMTP id p68mr738238qkb.120.1589496602347; Thu, 14 May 2020 15:50:02 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> From: Kyle Evans Date: Thu, 14 May 2020 17:49:51 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 22:50:03 -0000 On Thu, May 14, 2020 at 3:17 PM Julian H. Stacey wrote: > > Kyle Evans wrote: > > Hi, > > > > This is a heads up, given that I'm completely flipping our historical > > behavior- I intend to commit this review in a couple days' time > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > could have previously returned some data from the underlying > > filesystem in no particular standardized format. > > > > This is a still-standards-compliant switch from one > > implementation-defined behavior to another that's already been adopted > > in various other popular kernels, to include OpenBSD, MacOS, and > > Linux. > > > > Worth noting is that there's not really one largely-compelling reasons > > to switch this after so many years (unless you find yourself that > > irate when you accidentally `cat` a directory), but there are some > > benefits which are briefly discussed in the commentary around the > > review along with the history of the current behavior. > > > > This change also simplifies filesystem implementations to some extent. > > > > Thanks, > > > > Kyle Evans > > There is ZERO need for a spurious change at 2 days notice after 42+ years ! > Sorry, this was a sloppy wording/prediction. There's no way I would have gotten to committing it before Tuesday, even, with how overcommitted I am between FreeBSD and the physical world around me. > "cat ." as been supported since Unix V6 1978 or earlier, > no problem, even occasionaly useful. > Do you have examples? The entire point of this thread is to solicit valid complaints from 'the other side.' > Most FreeBSD users wont have heard of https://reviews.freebsd.org/D24596 > (& there's only 5 other people's opinions there, apart from proposer, > & skimming through the impression is far from un-qualified approval. > > kevans@ issued arch@ just a couple days notice of intention to commit. > arch@ is also not widely read, ( I jhs@ added CC hackers@) > > Many FreeBSD end users won't even be reading hackers@ (some not > even announce@,) & would notice just yet another pointless change > sometime after upgrade. > Sure- it's hard to know just how many lists to cross-post to. Thanks for adding -hackers@. > Do not force all FreeBSD users towards gratuitous change for personal > preference for Linux behaviour. Switch to Linux, Or hack a > personalised shell on BSD that does what you want when you type > "cat ." If it's later widely popular, use it as proof to re-propose. No Rush. > Suggestions like this are wholly unwelcome. If I wanted Linux semantics, I would instead hack on Linux and ditch FreeBSD entirely. I can weave together a Linux + BSD userland if that's really what I wanted, but alas- it's not. I want sane and consistent semantics here, given that most of our filesystems either already return EISDIR or just return some garbage that maybe resembles something useful to someone (e.g. ZFS, where it's not even clear that it was intended to allow vop_read of a dir). To a degree I also want to no longer fix application bugs because they assume here the implementation-defined semantics that almost the rest of the world has already opted for (again, at least OpenBSD, MacOS, Linux). Such bugs have wasted a lot of my already sparse time because they're not always trivial to identify, and the reward for keeping this around is almost nonexistent for most users of FreeBSD, a very large chunk of which run filesystems where `cat .` doesn't produce any meaningful data. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Thu May 14 23:53:19 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 97A282E456D for ; Thu, 14 May 2020 23:53:19 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NSzM3PGgz46cD; Thu, 14 May 2020 23:53:19 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id E42AC12B53; Thu, 14 May 2020 23:53:18 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Thu, 14 May 2020 16:53:16 -0700 (PDT) From: Don Lewis Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: Cy Schubert cc: Kyle Evans , "freebsd-arch@freebsd.org" In-Reply-To: <202005141954.04EJsCtH036247@slippy.cwsent.com> Message-ID: References: <202005141954.04EJsCtH036247@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 23:53:19 -0000 On 14 May, Cy Schubert wrote: > In message om> > , Kyle Evans writes: >> Hi, >> >> This is a heads up, given that I'm completely flipping our historical >> behavior- I intend to commit this review in a couple days' time >> without substantial objection: https://reviews.freebsd.org/D24596 >> >> With this, FreeBSD 13 will not allow read() of a directory fd, which >> could have previously returned some data from the underlying >> filesystem in no particular standardized format. >> >> This is a still-standards-compliant switch from one >> implementation-defined behavior to another that's already been adopted >> in various other popular kernels, to include OpenBSD, MacOS, and >> Linux. >> >> Worth noting is that there's not really one largely-compelling reasons >> to switch this after so many years (unless you find yourself that >> irate when you accidentally `cat` a directory), but there are some >> benefits which are briefly discussed in the commentary around the >> review along with the history of the current behavior. >> >> This change also simplifies filesystem implementations to some extent. > > OpenBSD has done this for a while and more importantly Linux. Which causes annoying noise to stderr if you 'grep something *' if there are directories in the working directory. From owner-freebsd-arch@freebsd.org Thu May 14 23:58:28 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 945322E482D for ; Thu, 14 May 2020 23:58:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NT5J3RMFz46jm; Thu, 14 May 2020 23:58:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 647D212B54; Thu, 14 May 2020 23:58:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f173.google.com with SMTP id t25so519939qtc.0; Thu, 14 May 2020 16:58:28 -0700 (PDT) X-Gm-Message-State: AOAM532d9s7dR3hpbkfxb8myfw+zDvlkDrcO/Rs8cwEAjoNqEkYwjgHm UI6LLFRj2h5Y6Xb23IEAA7icSdv3ZEEsxhnDxSI= X-Google-Smtp-Source: ABdhPJzjwCUjbTc3V7Ihk2hSVknHmQcNsH6R0KQLsCBjFp8ni1YKQPjWoxRI1NfRrUh2Nhb+U6FiF4xs+og25GyyPvI= X-Received: by 2002:ac8:6f2f:: with SMTP id i15mr789384qtv.53.1589500707974; Thu, 14 May 2020 16:58:27 -0700 (PDT) MIME-Version: 1.0 References: <202005141954.04EJsCtH036247@slippy.cwsent.com> In-Reply-To: From: Kyle Evans Date: Thu, 14 May 2020 18:58:17 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: Don Lewis Cc: Cy Schubert , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 23:58:28 -0000 On Thu, May 14, 2020 at 6:53 PM Don Lewis wrote: > > On 14 May, Cy Schubert wrote: > > In message > om> > > , Kyle Evans writes: > >> Hi, > >> > >> This is a heads up, given that I'm completely flipping our historical > >> behavior- I intend to commit this review in a couple days' time > >> without substantial objection: https://reviews.freebsd.org/D24596 > >> > >> With this, FreeBSD 13 will not allow read() of a directory fd, which > >> could have previously returned some data from the underlying > >> filesystem in no particular standardized format. > >> > >> This is a still-standards-compliant switch from one > >> implementation-defined behavior to another that's already been adopted > >> in various other popular kernels, to include OpenBSD, MacOS, and > >> Linux. > >> > >> Worth noting is that there's not really one largely-compelling reasons > >> to switch this after so many years (unless you find yourself that > >> irate when you accidentally `cat` a directory), but there are some > >> benefits which are briefly discussed in the commentary around the > >> review along with the history of the current behavior. > >> > >> This change also simplifies filesystem implementations to some extent. > > > > OpenBSD has done this for a while and more importantly Linux. > > Which causes annoying noise to stderr if you 'grep something *' if there > are directories in the working directory. > This is one that I actually find particularly annoying when I'm on a UFS system, as my partial inquiries will sometimes match the names of directory entries, so I'll get: Binary file ${dirname} matches That's almost never what I wanted, though. From owner-freebsd-arch@freebsd.org Fri May 15 01:10:25 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 55C5F2E5F31; Fri, 15 May 2020 01:10:25 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mail.steinkamm.com (mail.steinkamm.com [194.127.175.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "steinkamm.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NVhJ06vFz4B2b; Fri, 15 May 2020 01:10:23 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from trajan.stk.cx (trajan.stk.cx [10.8.8.110]) by basis.steinkamm.com (8.15.2/8.15.2) with ESMTPS id 04F1AImV005131 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 15 May 2020 03:10:18 +0200 (CEST) (envelope-from arne@steinkamm.com) Received: from trajan.stk.cx (localhost [127.0.0.1]) by trajan.stk.cx (8.15.2/8.15.2) with ESMTPS id 04F1AIw7045627 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 03:10:18 +0200 (CEST) (envelope-from arne@trajan.stk.cx) Received: (from arne@localhost) by trajan.stk.cx (8.15.2/8.15.2/Submit) id 04F1AFtB045613; Fri, 15 May 2020 03:10:15 +0200 (CEST) (envelope-from arne) Date: Fri, 15 May 2020 03:10:15 +0200 From: Arne Steinkamm To: "freebsd-arch@freebsd.org" , hackers@freebsd.org Cc: "Julian H. Stacey" , Kyle Evans Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515011015.GV82984@trajan.stk.cx> Reply-To: arne@Steinkamm.COM References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <20200514202250.GS82984@trajan.stk.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200514202250.GS82984@trajan.stk.cx> User-Agent: Mutt@Trajan/1.12.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on basis.steinkamm.com X-Rspamd-Queue-Id: 49NVhJ06vFz4B2b X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of arne@Steinkamm.COM has no SPF policy when checking 194.127.175.194) smtp.mailfrom=arne@Steinkamm.COM X-Spamd-Result: default: False [1.85 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[arne@Steinkamm.COM]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.02)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[Steinkamm.COM]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.77)[0.773,0]; NEURAL_HAM_MEDIUM(-0.12)[-0.118,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[freebsd-arch@Steinkamm.COM,arne@Steinkamm.COM]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:34646, ipnet:194.127.175.0/24, country:DE]; FROM_NEQ_ENVFROM(0.00)[freebsd-arch@Steinkamm.COM,arne@Steinkamm.COM]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 01:10:25 -0000 On Thu, May 14, 2020 at 10:17:00PM +0200, Julian H. Stacey wrote: > > "cat ." as been supported since Unix V6 1978 or earlier, > no problem, even occasionaly useful. > > Most FreeBSD users wont have heard of https://reviews.freebsd.org/D24596 > (& there's only 5 other people's opinions there, apart from proposer, > & skimming through the impression is far from un-qualified approval. > > kevans@ issued arch@ just a couple days notice of intention to commit. > arch@ is also not widely read, ( I jhs@ added CC hackers@) +1 !!! .//. Arne -- Arne Steinkamm | Home: Mail: arnesteinkammcom From owner-freebsd-arch@freebsd.org Fri May 15 01:13:25 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8DA5A2E6140 for ; Fri, 15 May 2020 01:13:25 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mail.steinkamm.com (mail.steinkamm.com [194.127.175.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "steinkamm.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NVlm5HJrz4BM4; Fri, 15 May 2020 01:13:24 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from trajan.stk.cx (trajan.stk.cx [10.8.8.110]) by basis.steinkamm.com (8.15.2/8.15.2) with ESMTPS id 04F1DG8W005208 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 15 May 2020 03:13:16 +0200 (CEST) (envelope-from arne@steinkamm.com) Received: from trajan.stk.cx (localhost [127.0.0.1]) by trajan.stk.cx (8.15.2/8.15.2) with ESMTPS id 04F1D4WP072525 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 03:13:04 +0200 (CEST) (envelope-from arne@trajan.stk.cx) Received: (from arne@localhost) by trajan.stk.cx (8.15.2/8.15.2/Submit) id 04F1CwrG072009; Fri, 15 May 2020 03:12:58 +0200 (CEST) (envelope-from arne) Date: Fri, 15 May 2020 03:12:58 +0200 From: Arne Steinkamm To: freebsd-arch@freebsd.org Cc: Alan Somers , "Julian H. Stacey" , Kyle Evans Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515011258.GW82984@trajan.stk.cx> Reply-To: arne@Steinkamm.COM References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <20200514203030.GT82984@trajan.stk.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200514203030.GT82984@trajan.stk.cx> User-Agent: Mutt@Trajan/1.12.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on basis.steinkamm.com X-Rspamd-Queue-Id: 49NVlm5HJrz4BM4 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of arne@Steinkamm.COM has no SPF policy when checking 194.127.175.194) smtp.mailfrom=arne@Steinkamm.COM X-Spamd-Result: default: False [1.85 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[arne@Steinkamm.COM]; NEURAL_HAM_MEDIUM(-0.09)[-0.094,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[Steinkamm.COM]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.02)]; NEURAL_SPAM_LONG(0.75)[0.749,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[freebsd-arch@Steinkamm.COM,arne@Steinkamm.COM]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:34646, ipnet:194.127.175.0/24, country:DE]; FROM_NEQ_ENVFROM(0.00)[freebsd-arch@Steinkamm.COM,arne@Steinkamm.COM]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 01:13:25 -0000 On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote: > On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: > > > Kyle Evans wrote: > > > Hi, > > > > > > This is a heads up, given that I'm completely flipping our historical > > > behavior- I intend to commit this review in a couple days' time > > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > > could have previously returned some data from the underlying > > > filesystem in no particular standardized format. > > > > > > This is a still-standards-compliant switch from one > > > implementation-defined behavior to another that's already been adopted > > > in various other popular kernels, to include OpenBSD, MacOS, and > > > Linux. > > > > > > Worth noting is that there's not really one largely-compelling reasons > > > to switch this after so many years (unless you find yourself that > > > irate when you accidentally `cat` a directory), but there are some > > > benefits which are briefly discussed in the commentary around the > > > review along with the history of the current behavior. > > > > > > This change also simplifies filesystem implementations to some extent. > > > > > > Thanks, > > > > > > Kyle Evans > > > > There is ZERO need for a spurious change at 2 days notice after 42+ years ! > > > > "cat ." as been supported since Unix V6 1978 or earlier, > > no problem, even occasionaly useful. > > > > Really? When is that occasionally useful? I've never seen anything useful > come out of reading a directory. It's all about files in Unix... This is true since 1972. And files can be read! How many (bad programmed) shell scripts will break when directory files can't be read anymore? I have no idea. But I know for sure that there is no need to make this change. Not 1976, not 2020 nor in the future. .//. Arne -- Arne Steinkamm | Home: Mail: arnesteinkammcom From owner-freebsd-arch@freebsd.org Fri May 15 01:43:21 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8AE282E6D7C for ; Fri, 15 May 2020 01:43:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NWQJ2dySz4Cd1 for ; Fri, 15 May 2020 01:43:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x830.google.com with SMTP id l1so666151qtp.6 for ; Thu, 14 May 2020 18:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MF4LHBbQj2bV3pJegMbVXmLdgnqOH5mN6S8Lscca1GE=; b=pC08eHTA+EIIjf4ZEJVn/MoiypUC91cyxt7Lk5cbKiuxPZgoVvia6SARjntjaSLcBC mWvTfG0qIuhuhbdAdoFX+6Qc26QudJgIQCK1D6VwRImAIrB9i1lOPkU234sfkS4MjbsI 0nuj/V+iw31KHcDZYJ5d/eKevelcmgZ4Urfs2m931iJgE5dYzqqS0b05A+DnGk770JYV w/pF1gaNrWAMpX45bdWd0SJtzeGWQQbkGTaAzHozNLx0Q+mH1OTW7KrKDYRfABA8dDcp B2vkm4Id4NzH0Hq0vL0tbla3Fv2SrmQ82Ff3YySqT/q3r93cyMbmAtpbse7XUbpmkjkC 43Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MF4LHBbQj2bV3pJegMbVXmLdgnqOH5mN6S8Lscca1GE=; b=iEUqjnxP8ysO7z4mMHqTrSAf6jM4QNAinn4wz0h8auuyhZ1q3f9h3u3SPkjKPwbrs1 HeFLfqP/f2Cp1GH9+hRfig+EJwKtSBIDrq+V894dNREcwcW1vStxmUpJZQ63NjgIq5sE 5HKjLfsqtGtm15hyJby6u5GI+it8EbB4Xb64J5tfOQsCZzINYq9eZCFBe6PxsEl1JyUd B8zLh1O9xu4Yh5JRMNp7oW+qwZJcGl9HmgBl9ILBY2JzfUFRN4axuRbYkwMW887af1wG xxGyKM1gsiMuiESCLhR1DS2MkYH0o7WjQmxtdWiz3H3kIF7CEo1dr1s6BOvsyfzGkTDi 2AVw== X-Gm-Message-State: AOAM530pA1PWSqKj7hAzMWINhyzsClmOG2NWQtVKlrtiE33/MYuLOn7t WO54fWZGoo6KNdI/Jc2l0KmxW2ngQdidthCosnhJig== X-Google-Smtp-Source: ABdhPJyCqI1U64dWt9yam1+UevkAzCEB3Ts1/q2sAc6goCYjZbSAeuOQaRzbyFMSXLapc9M0ct8IA5gRN26QRn7+3wc= X-Received: by 2002:ac8:f94:: with SMTP id b20mr1141500qtk.291.1589506999207; Thu, 14 May 2020 18:43:19 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <20200514203030.GT82984@trajan.stk.cx> <20200515011258.GW82984@trajan.stk.cx> In-Reply-To: <20200515011258.GW82984@trajan.stk.cx> From: Warner Losh Date: Thu, 14 May 2020 19:43:06 -0600 Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: arne@steinkamm.com Cc: freebsd-arch@freebsd.org, Alan Somers , "Julian H. Stacey" , Kyle Evans X-Rspamd-Queue-Id: 49NWQJ2dySz4Cd1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=pC08eHTA; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::830) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[0.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.00)[ip: (-9.22), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.42), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 01:43:21 -0000 On Thu, May 14, 2020, 7:14 PM Arne Steinkamm wrote: > On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote: > > On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey > wrote: > > > > > Kyle Evans wrote: > > > > Hi, > > > > > > > > This is a heads up, given that I'm completely flipping our historical > > > > behavior- I intend to commit this review in a couple days' time > > > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > > > > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > > > could have previously returned some data from the underlying > > > > filesystem in no particular standardized format. > > > > > > > > This is a still-standards-compliant switch from one > > > > implementation-defined behavior to another that's already been > adopted > > > > in various other popular kernels, to include OpenBSD, MacOS, and > > > > Linux. > > > > > > > > Worth noting is that there's not really one largely-compelling > reasons > > > > to switch this after so many years (unless you find yourself that > > > > irate when you accidentally `cat` a directory), but there are some > > > > benefits which are briefly discussed in the commentary around the > > > > review along with the history of the current behavior. > > > > > > > > This change also simplifies filesystem implementations to some > extent. > > > > > > > > Thanks, > > > > > > > > Kyle Evans > > > > > > There is ZERO need for a spurious change at 2 days notice after 42+ > years ! > > > > > > "cat ." as been supported since Unix V6 1978 or earlier, > > > no problem, even occasionaly useful. > > > > > > > Really? When is that occasionally useful? I've never seen anything > useful > > come out of reading a directory. > > It's all about files in Unix... > > This is true since 1972. > > And files can be read! > > How many (bad programmed) shell scripts will break when directory files > can't > be read anymore? I have no idea. > > But I know for sure that there is no need to make this change. > Not 1976, not 2020 nor in the future Why do you need this to work? It can disclose unwanted data... Warner .//. Arne > > -- > Arne Steinkamm | Home: Mail: arnesteinkammcom > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Fri May 15 05:10:46 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A96AF2EA2B2; Fri, 15 May 2020 05:10:46 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nc1f3s2Sz4Mch; Fri, 15 May 2020 05:10:46 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 7267D15081; Fri, 15 May 2020 05:10:46 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f178.google.com with SMTP id n14so1356505qke.8; Thu, 14 May 2020 22:10:46 -0700 (PDT) X-Gm-Message-State: AOAM5330gz+2qtY2QcG8BIQCVcafJhyb9fbxOltEXeiVeFziQBbnCLTC oi1UOC5o6S/1kkvXlUDh6Dcmjx/+7TQVSHGzgC0= X-Google-Smtp-Source: ABdhPJwEHWGNVqdxTqk+9EMmeY/wUZXSzJq9hkYFicsfGqLgP8PnKIIAvYac7WuBarCS4TKGJo5w8xOK3B9YkwqeQ7A= X-Received: by 2002:a37:8c4:: with SMTP id 187mr1770425qki.34.1589519446067; Thu, 14 May 2020 22:10:46 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> In-Reply-To: <33549.1589488226@critter.freebsd.dk> From: Kyle Evans Date: Fri, 15 May 2020 00:10:35 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: Poul-Henning Kamp Cc: Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 05:10:46 -0000 On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote: > > -------- > In message > , Alan Somers writes: > > >Really? When is that occasionally useful? I've never seen anything useful > >come out of reading a directory. > > Two things I have done over the years: > > Figure out which filenames prevent a enormous but sparse directory > from being compacted. > > Figure out which control characters were in a filename. > Can we explore the possibility of using fsdb(8) to fulfill these needs in a way that you'd be comfortable with? I am thoroughly motivated and willing to do what I can to find a good path forward. We could add a sysctl and remove the functionality from other filesystems that aren't necessarily providing useful information and likely haven't been audited for similar disclosures to https://www.freebsd.org/security/advisories/FreeBSD-SA-19:10.ufs.asc that may be exacerbated by read(2) on a dirfd, but I'd like to see if there's any compromise that we can make where the compromise on my side is that I have to put in the effort to otherwise enable presented valid use-cases in an agreeable manner. Is there anything that I, as a developer that knows very little about UFS and even less when compared to someone such as yourself, can do to facilitate making this as easy as possible with the tooling otherwise available? Looking at fsdb(8) briefly on this UFS partition I just spun up, it seems as a somewhat low-hanging fruit that we could (in some/many cases) infer a disk device from a standard directory/file path and prompt for confirmation based on that, opening up to the proper inode, even, as an example (wording would differ, and apologies for the formatting): root@shiva:/mnt# stat etc 682 12928 drwxr-xr-x 2 root wheel 26456 512 "May 14 23:58:27 2020" "May 14 23:58:27 2020" "May 14 23:58:27 2020" "May 14 23:58:27 2020" 32768 8 0 etc root@shiva:/mnt# fsdb etc etc is not a disk device, but is mounted from /dev/md1. Use /dev/md1? [yn] y ** /dev/md1 (NO WRITE) Editing file system `/dev/md1' Last Mounted on /mnt current inode: directory I=12928 MODE=40755 SIZE=512 BTIME=May 14 23:58:27 2020 [611088000 nsec] MTIME=May 14 23:58:27 2020 [614391000 nsec] CTIME=May 14 23:58:27 2020 [614391000 nsec] ATIME=May 14 23:58:27 2020 [614391000 nsec] OWNER=root GRP=wheel LINKCNT=2 FLAGS=0 BLKCNT=8 GEN=a15cce24 fsdb (inum: 12928)> ls slot 0 off 0 ino 12928 reclen 12: directory, `.' slot 1 off 12 ino 2 reclen 500: directory, `..' fsdb (inum: 12928)> Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Thu May 14 20:23:07 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 752DE2DE422; Thu, 14 May 2020 20:23:07 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mail.steinkamm.com (mail.steinkamm.com [194.127.175.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "steinkamm.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NNJp0SXnz3Ncp; Thu, 14 May 2020 20:23:05 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from trajan.stk.cx (trajan.stk.cx [10.8.8.110]) by basis.steinkamm.com (8.15.2/8.15.2) with ESMTPS id 04EKMsNZ000970 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 14 May 2020 22:22:54 +0200 (CEST) (envelope-from arne@steinkamm.com) Received: from trajan.stk.cx (localhost [127.0.0.1]) by trajan.stk.cx (8.15.2/8.15.2) with ESMTPS id 04EKMp7o036258 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 22:22:51 +0200 (CEST) (envelope-from arne@trajan.stk.cx) Received: (from arne@localhost) by trajan.stk.cx (8.15.2/8.15.2/Submit) id 04EKMoYH036081; Thu, 14 May 2020 22:22:50 +0200 (CEST) (envelope-from arne) Date: Thu, 14 May 2020 22:22:50 +0200 From: Arne Steinkamm To: "Julian H. Stacey" Cc: Kyle Evans , "freebsd-arch@freebsd.org" , hackers@freebsd.org, arne@steinkamm.com Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200514202250.GS82984@trajan.stk.cx> Reply-To: arne@Steinkamm.COM References: <202005142017.04EKH0aA093503@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> User-Agent: Mutt@Trajan/1.12.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on basis.steinkamm.com X-Rspamd-Queue-Id: 49NNJp0SXnz3Ncp X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of arne@Steinkamm.COM has no SPF policy when checking 194.127.175.194) smtp.mailfrom=arne@Steinkamm.COM X-Spamd-Result: default: False [1.73 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[arne@Steinkamm.COM]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.07)[-0.072,0]; IP_SCORE(-0.00)[country: DE(-0.02)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[Steinkamm.COM]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.61)[0.610,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:34646, ipnet:194.127.175.0/24, country:DE]; FROM_NEQ_ENVFROM(0.00)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; RCVD_TLS_ALL(0.00)[] X-Mailman-Approved-At: Fri, 15 May 2020 06:31:31 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:23:07 -0000 On Thu, May 14, 2020 at 10:17:00PM +0200, Julian H. Stacey wrote: > > "cat ." as been supported since Unix V6 1978 or earlier, > no problem, even occasionaly useful. > > Most FreeBSD users wont have heard of https://reviews.freebsd.org/D24596 > (& there's only 5 other people's opinions there, apart from proposer, > & skimming through the impression is far from un-qualified approval. > > kevans@ issued arch@ just a couple days notice of intention to commit. > arch@ is also not widely read, ( I jhs@ added CC hackers@) +1 !!! .//. Arne -- Arne Steinkamm | Home: Mail: arnesteinkammcom Tel.: +49.89.21031004 | Gröbenbachweg 13, 82178 Puchheim, GERMANY From owner-freebsd-arch@freebsd.org Thu May 14 20:32:32 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 992042DEB45; Thu, 14 May 2020 20:32:32 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mail.steinkamm.com (mail.steinkamm.com [194.127.175.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "steinkamm.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NNWh2HgKz3PTg; Thu, 14 May 2020 20:32:32 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from trajan.stk.cx (trajan.stk.cx [10.8.8.110]) by basis.steinkamm.com (8.15.2/8.15.2) with ESMTPS id 04EKUiFj001065 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 14 May 2020 22:30:44 +0200 (CEST) (envelope-from arne@steinkamm.com) Received: from trajan.stk.cx (localhost [127.0.0.1]) by trajan.stk.cx (8.15.2/8.15.2) with ESMTPS id 04EKUZht078170 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 22:30:35 +0200 (CEST) (envelope-from arne@trajan.stk.cx) Received: (from arne@localhost) by trajan.stk.cx (8.15.2/8.15.2/Submit) id 04EKUUgD077625; Thu, 14 May 2020 22:30:30 +0200 (CEST) (envelope-from arne) Date: Thu, 14 May 2020 22:30:30 +0200 From: Arne Steinkamm To: Alan Somers Cc: "Julian H. Stacey" , Kyle Evans , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , arne@steinkamm.com Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200514203030.GT82984@trajan.stk.cx> Reply-To: arne@Steinkamm.COM References: <202005142017.04EKH0aA093503@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt@Trajan/1.12.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on basis.steinkamm.com X-Rspamd-Queue-Id: 49NNWh2HgKz3PTg X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.96 / 15.00]; NEURAL_HAM_MEDIUM(-0.96)[-0.964,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-Mailman-Approved-At: Fri, 15 May 2020 06:32:18 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:32:32 -0000 On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote: > On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: > > > Kyle Evans wrote: > > > Hi, > > > > > > This is a heads up, given that I'm completely flipping our historical > > > behavior- I intend to commit this review in a couple days' time > > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > > could have previously returned some data from the underlying > > > filesystem in no particular standardized format. > > > > > > This is a still-standards-compliant switch from one > > > implementation-defined behavior to another that's already been adopted > > > in various other popular kernels, to include OpenBSD, MacOS, and > > > Linux. > > > > > > Worth noting is that there's not really one largely-compelling reasons > > > to switch this after so many years (unless you find yourself that > > > irate when you accidentally `cat` a directory), but there are some > > > benefits which are briefly discussed in the commentary around the > > > review along with the history of the current behavior. > > > > > > This change also simplifies filesystem implementations to some extent. > > > > > > Thanks, > > > > > > Kyle Evans > > > > There is ZERO need for a spurious change at 2 days notice after 42+ years ! > > > > "cat ." as been supported since Unix V6 1978 or earlier, > > no problem, even occasionaly useful. > > > > Really? When is that occasionally useful? I've never seen anything useful > come out of reading a directory. It's all about files in Unix... This is true since 1972. And files can be read! How many (bad programmed) shell scripts will break when directory files can't be read anymore? I have no idea. But I know for sure that there is no need to make this change. Not 1976, not 2020 nor in the future. .//. Arne -- Arne Steinkamm | Home: Mail: arnesteinkammcom From owner-freebsd-arch@freebsd.org Thu May 14 22:19:24 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4D7C72E205B; Thu, 14 May 2020 22:19:24 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NQtz6H4Jz41sg; Thu, 14 May 2020 22:19:23 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 04EMJXOq044241 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 May 2020 15:19:40 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: "freebsd-arch@freebsd.org" , , Kyle Evans In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> From: Chris Reply-To: bsd-lists@BSDforge.com To: "Julian H. Stacey" Subject: Re: [HEADSUP] Disallowing read() of a directory fd Date: Thu, 14 May 2020 15:19:39 -0700 Message-Id: <1a951a29e3ca52c0ebd823f4a4437412@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49NQtz6H4Jz41sg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.09 / 15.00]; NEURAL_HAM_MEDIUM(-0.13)[-0.129,0]; NEURAL_HAM_LONG(-0.96)[-0.962,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-Mailman-Approved-At: Fri, 15 May 2020 06:32:54 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 22:19:24 -0000 On Thu, 14 May 2020 22:17:00 +0200 Julian H=2E Stacey jhs@berklix=2Ecom said > Kyle Evans wrote: > > Hi, > >=20 > > This is a heads up, given that I'm completely flipping our historical > > behavior- I intend to commit this review in a couple days' time > > without substantial objection: https://reviews=2Efreebsd=2Eorg/D24596 > >=20 > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > could have previously returned some data from the underlying > > filesystem in no particular standardized format=2E > >=20 > > This is a still-standards-compliant switch from one > > implementation-defined behavior to another that's already been adopted > > in various other popular kernels, to include OpenBSD, MacOS, and > > Linux=2E Completely different file systems=2E This is a non-reason/excuse to impose such a change=2E > >=20 > > Worth noting is that there's not really one largely-compelling reasons > > to switch this after so many years (unless you find yourself that > > irate when you accidentally `cat` a directory), but there are some > > benefits which are briefly discussed in the commentary around the > > review along with the history of the current behavior=2E > >=20 > > This change also simplifies filesystem implementations to some extent=2E > >=20 > > Thanks, > >=20 > > Kyle Evans >=20 > There is ZERO need for a spurious change at 2 days notice after 42+ years= ! +2! >=20 > "cat =2E" as been supported since Unix V6 1978 or earlier,=20 > no problem, even occasionaly useful=2E >=20 > Most FreeBSD users wont have heard of https://reviews=2Efreebsd=2Eorg/D24596 > (& there's only 5 other people's opinions there, apart from proposer, > & skimming through the impression is far from un-qualified approval=2E >=20 >=20 > Do not force all FreeBSD users towards gratuitous change for personal > preference for Linux behaviour=2E Switch to Linux, Or hack a > personalised shell on BSD that does what you want when you type > "cat =2E" If it's later widely popular, use it as proof to re-propose=2E No > Rush=2E This bikeshed is already the correct color=2E Please leave it as is=2E >=20 > A bigger issue is due notice procedure, & respect to FreeBSD stability of > code > & users expectations of predictability=2E > Unwarned playing about would detract from FreeBSD's business image=2E Amen to that=2E >=20 > Cheers > -- > Julian Stacey, Consultant Systems Engineer, BSD Linux > http://berklix=2Ecom/jhs/ > http://www=2Eberklix=2Eorg/corona/#masks Tie 2 handkerchiefs or 1 pillow cas= e=2E=20 > Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec=2E 20= 20 --Chris From owner-freebsd-arch@freebsd.org Fri May 15 07:41:53 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7C88A2ECEF5 for ; Fri, 15 May 2020 07:41:53 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NgMz4FnWz4VD4 for ; Fri, 15 May 2020 07:41:51 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from venus.yoonka.com ([10.70.7.24]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id 04F7fhEH051900 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 15 May 2020 07:41:44 GMT (envelope-from list1@gjunka.com) X-Authentication-Warning: msa1.earth.yoonka.com: Host [10.70.7.24] claimed to be venus.yoonka.com Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: freebsd-arch@freebsd.org References: <202005142017.04EKH0aA093503@fire.js.berklix.net> From: Grzegorz Junka Message-ID: Date: Fri, 15 May 2020 07:41:43 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 49NgMz4FnWz4VD4 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list1@gjunka.com designates 88.98.225.149 as permitted sender) smtp.mailfrom=list1@gjunka.com X-Spamd-Result: default: False [-5.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:88.98.225.149]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; HAS_XAW(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gjunka.com]; IP_SCORE(-3.57)[ip: (-9.37), ipnet: 88.98.192.0/18(-4.68), asn: 56478(-3.75), country: GB(-0.07)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:56478, ipnet:88.98.192.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 07:41:53 -0000 On 14/05/2020 20:17, Julian H. Stacey wrote: > Kyle Evans wrote: >> Hi, >> >> This is a heads up, given that I'm completely flipping our historical >> behavior- I intend to commit this review in a couple days' time >> without substantial objection: https://reviews.freebsd.org/D24596 >> >> With this, FreeBSD 13 will not allow read() of a directory fd, which >> could have previously returned some data from the underlying >> filesystem in no particular standardized format. >> >> This is a still-standards-compliant switch from one >> implementation-defined behavior to another that's already been adopted >> in various other popular kernels, to include OpenBSD, MacOS, and >> Linux. >> >> Worth noting is that there's not really one largely-compelling reasons >> to switch this after so many years (unless you find yourself that >> irate when you accidentally `cat` a directory), but there are some >> benefits which are briefly discussed in the commentary around the >> review along with the history of the current behavior. >> >> This change also simplifies filesystem implementations to some extent. >> >> Thanks, >> >> Kyle Evans > There is ZERO need for a spurious change at 2 days notice after 42+ years ! > > "cat ." as been supported since Unix V6 1978 or earlier, > no problem, even occasionaly useful. I see it as an attempt at unifying the behavior across filesystems. 42+ years ago we didn't have so many of them. And I don't see the age argument as valid when fixing inconsistent behavior, rather red herring that it hasn't been addressed sooner! > Most FreeBSD users wont have heard of https://reviews.freebsd.org/D24596 > (& there's only 5 other people's opinions there, apart from proposer, > & skimming through the impression is far from un-qualified approval. > > kevans@ issued arch@ just a couple days notice of intention to commit. > arch@ is also not widely read, ( I jhs@ added CC hackers@) > > Many FreeBSD end users won't even be reading hackers@ (some not > even announce@,) & would notice just yet another pointless change > sometime after upgrade. Are you opposing for the sake of being different, or because you were not involved in the decision process, or are you just trying to postpone the process a little bit for it to have more scrutiny, or are you genuinely against the change and will actively seek for ways to abandon it? > Do not force all FreeBSD users towards gratuitous change for personal > preference for Linux behaviour. Switch to Linux, Or hack a > personalised shell on BSD that does what you want when you type > "cat ." If it's later widely popular, use it as proof to re-propose. No Rush. The committer explained in the commit request that it's to avoid bugs and make the behavior more consistent. The fact that you don't believe him and think that he has a hidden agenda (i.e. personal preference towards Linux) should not be enough reason to abandon it unless proven. As a FreeBSD user I am all about less bugs in the software I am using and frankly I don't care about "cat ." GrzegorzJ From owner-freebsd-arch@freebsd.org Fri May 15 07:51:47 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 18B3B2ED2BB; Fri, 15 May 2020 07:51:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49NgbP30b7z4VdH; Fri, 15 May 2020 07:51:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id C2E501AF18C; Fri, 15 May 2020 07:51:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id 04F7pgrH035503 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 07:51:42 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id 04F7pgXZ035502; Fri, 15 May 2020 07:51:42 GMT (envelope-from phk) To: Kyle Evans cc: Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: From: "Poul-Henning Kamp" References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35500.1589529102.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2020 07:51:42 +0000 Message-ID: <35501.1589529102@critter.freebsd.dk> X-Rspamd-Queue-Id: 49NgbP30b7z4VdH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.78 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.872,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.95)[-0.954,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.04)[ip: (0.06), ipnet: 130.225.0.0/16(0.08), asn: 1835(0.08), country: EU(-0.01)]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 07:51:47 -0000 -------- In message , Kyle Evans writes: >On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wr= ote: >Can we explore the possibility of using fsdb(8) to fulfill these needs >in a way that you'd be comfortable with? First, I am perfectly comfortable with fsdb(8), but in both the two scenarios it was much less timeconsuming to do: strings < /some/directory | head Which immediately gives you the first filenames in the directory, without waiting for ls(1) to read the entire directory, which in this case was well north of 100MB. In the other case hexdump -C < /some/directory | grep part_of_suspect_filename gave me the answer faster than I could have started fsdb, it gave me the answer in convenient hexadecimal, and besides it was not = a UFS filesystem. Second, one of the major reasons, probably about 3/4 of the total reason I ended up in FreeBSD, was because of some utterly shit experiences with commercial operating systems, where I had been in a tight corner at 00-dark o'clock, and run straight into something some idiot of at the vendor thought root should not be able to do "for their own safety". This change falls right into that category: If root wants to hexdump a directory, an entire bloody disk, or even if root wants to go and do binary surgery on a mounted file system with a hex-editor, root should be able to do that. She may have to `sysctl kern.warranty_voided=3D999` first, to disable *under normal circumstances* reasonable and sensible protections. I'm perfectly fine with that: We do not want to make being root a minefield, and I myself put the ability to munge mounted filesystems under such a interlock in GEOM. But we should not make it *impossible* to do these things, and in particular, we should not make them require a reboot, because ten times out of nine, when you find yourself doing this kind of shit, it is usually because you're pretty sure everything is lost if you reboot. Summary: I'm perfectly fine with read(2) returning error on a directory *under normal circumstances*, and I think it makes good sense by protecting a lot of terminals from a lot of binary garbage. But there is absolutely no reason to make it *impossible* for a competent root to do what competent roots do. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Fri May 15 09:47:48 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BA4262F050D; Fri, 15 May 2020 09:47:48 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nk9J4HMHz4bVv; Fri, 15 May 2020 09:47:48 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MacBook-Pro-449.fritz.box (p200300CD5F25D600ACFE788A6E98E203.dip0.t-ipconnect.de [IPv6:2003:cd:5f25:d600:acfe:788a:6e98:e203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 23C5618E86; Fri, 15 May 2020 09:47:47 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: [HEADSUP] Disallowing read() of a directory fd References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <20200514203030.GT82984@trajan.stk.cx> <20200515011258.GW82984@trajan.stk.cx> From: =?UTF-8?Q?Stefan_E=c3=9fer?= Autocrypt: addr=se@freebsd.org; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Cc: freebsd-arch@freebsd.org, FreeBSD Hackers To: Arne Steinkamm Message-ID: Date: Fri, 15 May 2020 11:47:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200515011258.GW82984@trajan.stk.cx> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 09:47:48 -0000 Am 15.05.20 um 03:12 schrieb Arne Steinkamm: > On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote: >> On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: >> >>> Kyle Evans wrote: >>>> Hi, >>>> >>>> This is a heads up, given that I'm completely flipping our historical >>>> behavior- I intend to commit this review in a couple days' time >>>> without substantial objection: https://reviews.freebsd.org/D24596 >>>> >>>> With this, FreeBSD 13 will not allow read() of a directory fd, which >>>> could have previously returned some data from the underlying >>>> filesystem in no particular standardized format. >>>> >>>> This is a still-standards-compliant switch from one >>>> implementation-defined behavior to another that's already been adopted >>>> in various other popular kernels, to include OpenBSD, MacOS, and >>>> Linux. >>>> >>>> Worth noting is that there's not really one largely-compelling reasons >>>> to switch this after so many years (unless you find yourself that >>>> irate when you accidentally `cat` a directory), but there are some >>>> benefits which are briefly discussed in the commentary around the >>>> review along with the history of the current behavior. >>>> >>>> This change also simplifies filesystem implementations to some extent. >>>> >>>> Thanks, >>>> >>>> Kyle Evans >>> >>> There is ZERO need for a spurious change at 2 days notice after 42+ years ! >>> >>> "cat ." as been supported since Unix V6 1978 or earlier, >>> no problem, even occasionaly useful. >>> >> >> Really? When is that occasionally useful? I've never seen anything useful >> come out of reading a directory. > > It's all about files in Unix... > > This is true since 1972. > > And files can be read! > > How many (bad programmed) shell scripts will break when directory files can't > be read anymore? I have no idea. And how many shell scripts will break if you migrate from UFS to ZFS which does not return the same data? Reading a directory entry as a byte stream for low level debugging has been the only valid use case I've seen in this thread. And I'm convinced that any developer going to work on that part of UFS would consider adding debug code to provide or display that information (or remove the error return just for local testing) a minor annoyance. > But I know for sure that there is no need to make this change. > Not 1976, not 2020 nor in the future. There might be no need in the strict sense, but some reasons have been provided: - Linux, macOS, OpenBSD do it (not a good reason in itself) - applications developed with Linux or macOS in mind might expect it (and that is a valid reason, IMHO) - currently we make no guarantee with regard to success or failure of reading a directory - it depends on the choice made by the file system (and technical limitations, e.g. in case of NFS) - information could be leaked that is of use to an attacker (and that might have been the main reason it has been prohibited in OpenBSD) Every script run by an unprivileged user ought to be able to deal with a directory that cannot be read e.g. because of insufficient privilege. A script run by root should never depend on unspecified behavior (even if in case that it has been defined behavior in BSD for a long time). I'm convinced that there is more code today that has been developed on Linux and breaks on FreeBSD, unless specifically patched, then there are shell scripts that break when directory access is limited to the access functions provided for this purpose for decades. I've always been a strong supporter of POLA, but do not see how this suggested change is going to be a violation of that principle. We could make this change in -CURRENT, not MFC at all or after a long period of testing whether there is any fall-out, and then decide whether we want it backed out or controller by a tunable or sysctl. Such an experiment in -CURRENT (announced on the appropriate lists) should not cause any trouble or churn for developers and let us find out, if there really is some negative impact. Regards, STefan From owner-freebsd-arch@freebsd.org Fri May 15 11:14:17 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 58A2A2F2210; Fri, 15 May 2020 11:14:17 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nm551gRVz3CCw; Fri, 15 May 2020 11:14:17 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 0AC7D17778; Fri, 15 May 2020 11:14:17 +0000 (UTC) Date: Fri, 15 May 2020 13:14:13 +0200 From: Daniel Ebdrup Jensen To: freebsd-arch@freebsd.org, FreeBSD Hackers Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515111413.f42c4howkre4btnc@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-arch@freebsd.org, FreeBSD Hackers References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <20200514203030.GT82984@trajan.stk.cx> <20200515011258.GW82984@trajan.stk.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mw2ngzz6mbqcpkrd" Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 11:14:17 -0000 --mw2ngzz6mbqcpkrd Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 15, 2020 at 11:47:44AM +0200, Stefan E=DFer wrote: >And I'm convinced that any developer going to work on that part of UFS >would consider adding debug code to provide or display that information >(or remove the error return just for local testing) a minor annoyance. >[SNIP] > >Regards, STefan >_______________________________________________ >freebsd-arch@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" They could also add tracepoints for dtrace, and commit them to the tree so= =20 everyone can use them. :) Afterall, there's only +82k tracepoints (on FreeBSD 12.1-RELEASE, probably = more=20 in -CURRENT), so there's clearly room for improvement, especially when you = look=20 at the distribution with: dtrace -l | awk '{ print $2 }' | uniq -c | sort -n Yours, Daniel Ebdrup Jensen --mw2ngzz6mbqcpkrd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl6+eYVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87rujwgAuQKg8Ayh6U2D8oD7IwKEJQf/z6Xtu0JrhgJQ8VbBn2L99+rxT+xnjUnE duTPXCPmc8La3fueZRc3nJ0BDNaZCwyflAb1K87yY4HeJjvGsPS4laULJ6OpQMBe u35NRkMAojEL4CyeSUHEp0kF/qt32DbyDple80bEuI/S0TFcm1CWAmpKmd4qSyiL zpMWNIKarYjb2B9MsyARXQLQv+e/8exvf9w2KKyU7Yc8xHMJvS8/HvMoWhsGrPgZ qLC+Kz/w0fwcD5h5HYzwgr38vf0tykW1NTd4rAKy2sqgVSBW882tFosygrxN50q/ u8DopcJF47hKHBrOSPE5kezN+QOnVA== =GDAv -----END PGP SIGNATURE----- --mw2ngzz6mbqcpkrd-- From owner-freebsd-arch@freebsd.org Fri May 15 12:47:47 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 626D12F4B22; Fri, 15 May 2020 12:47:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Np8y51MYz3JBC; Fri, 15 May 2020 12:47:46 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 04FClh3b086498; Fri, 15 May 2020 05:47:43 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 04FClhsD086497; Fri, 15 May 2020 05:47:43 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202005151247.04FClhsD086497@gndrsh.dnsmgr.net> Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-Reply-To: To: =?UTF-8?Q?Stefan_E=C3=9Fer?= Date: Fri, 15 May 2020 05:47:43 -0700 (PDT) CC: Arne Steinkamm , freebsd-arch@freebsd.org, FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49Np8y51MYz3JBC X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.97 / 15.00]; NEURAL_HAM_MEDIUM(-0.97)[-0.967,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 12:47:47 -0000 > Am 15.05.20 um 03:12 schrieb Arne Steinkamm: > > On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote: > >> On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: > >> > >>> Kyle Evans wrote: > >>>> Hi, > >>>> > >>>> This is a heads up, given that I'm completely flipping our historical > >>>> behavior- I intend to commit this review in a couple days' time > >>>> without substantial objection: https://reviews.freebsd.org/D24596 > >>>> > >>>> With this, FreeBSD 13 will not allow read() of a directory fd, which > >>>> could have previously returned some data from the underlying > >>>> filesystem in no particular standardized format. > >>>> > >>>> This is a still-standards-compliant switch from one > >>>> implementation-defined behavior to another that's already been adopted > >>>> in various other popular kernels, to include OpenBSD, MacOS, and > >>>> Linux. > >>>> > >>>> Worth noting is that there's not really one largely-compelling reasons > >>>> to switch this after so many years (unless you find yourself that > >>>> irate when you accidentally `cat` a directory), but there are some > >>>> benefits which are briefly discussed in the commentary around the > >>>> review along with the history of the current behavior. > >>>> > >>>> This change also simplifies filesystem implementations to some extent. > >>>> > >>>> Thanks, > >>>> > >>>> Kyle Evans > >>> > >>> There is ZERO need for a spurious change at 2 days notice after 42+ years ! > >>> > >>> "cat ." as been supported since Unix V6 1978 or earlier, > >>> no problem, even occasionaly useful. > >>> > >> > >> Really? When is that occasionally useful? I've never seen anything useful > >> come out of reading a directory. > > > > It's all about files in Unix... > > > > This is true since 1972. > > > > And files can be read! > > > > How many (bad programmed) shell scripts will break when directory files can't > > be read anymore? I have no idea. > > And how many shell scripts will break if you migrate from UFS to ZFS > which does not return the same data? I believe there is some confusion over what the symantics of read means on a directory and what is being changed, and file protections. This change does not change the actual protection on a directory, so the effect on if [ -r ${pathname} ]; is none. > > Reading a directory entry as a byte stream for low level debugging has > been the only valid use case I've seen in this thread. > > And I'm convinced that any developer going to work on that part of UFS > would consider adding debug code to provide or display that information > (or remove the error return just for local testing) a minor annoyance. The use case is usually an emergency and these options are generally not very viable solutions. > > > But I know for sure that there is no need to make this change. > > Not 1976, not 2020 nor in the future. > > There might be no need in the strict sense, but some reasons have been > provided: > > - Linux, macOS, OpenBSD do it (not a good reason in itself) > > - applications developed with Linux or macOS in mind might expect it > (and that is a valid reason, IMHO) Thats actually a bad reason, as this only allows non portable code to remain non portable without consequence. > > - currently we make no guarantee with regard to success or failure of > reading a directory - it depends on the choice made by the file system > (and technical limitations, e.g. in case of NFS) > > - information could be leaked that is of use to an attacker (and that > might have been the main reason it has been prohibited in OpenBSD) > > Every script run by an unprivileged user ought to be able to deal with a > directory that cannot be read e.g. because of insufficient privilege. > > A script run by root should never depend on unspecified behavior (even > if in case that it has been defined behavior in BSD for a long time). > > I'm convinced that there is more code today that has been developed on > Linux and breaks on FreeBSD, unless specifically patched, then there are > shell scripts that break when directory access is limited to the access > functions provided for this purpose for decades. > > I've always been a strong supporter of POLA, but do not see how this > suggested change is going to be a violation of that principle. > > > We could make this change in -CURRENT, not MFC at all or after a long > period of testing whether there is any fall-out, and then decide whether > we want it backed out or controller by a tunable or sysctl. > > Such an experiment in -CURRENT (announced on the appropriate lists) > should not cause any trouble or churn for developers and let us find > out, if there really is some negative impact. I can support this change so long as there is a *RUN* time way to disable it for root which does not require a reboot of any kind. Much like Kirk, and Poul who have pointed out a use cases when doing a UFS data recovery this is a usefull feature. Often the directory tree is valid, but the file names are mangled. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Fri May 15 11:48:21 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 42C092F2D5C; Fri, 15 May 2020 11:48:21 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49NmrM3ZYTz3DjC; Fri, 15 May 2020 11:48:19 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 49NmrD3V77z6dX7; Fri, 15 May 2020 13:48:12 +0200 (CEST) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id Fuxcfmf7kiMM; Fri, 15 May 2020 13:48:09 +0200 (CEST) Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: =?UTF-8?Q?Stefan_E=c3=9fer?= , Arne Steinkamm Cc: freebsd-arch@freebsd.org, FreeBSD Hackers References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <20200514203030.GT82984@trajan.stk.cx> <20200515011258.GW82984@trajan.stk.cx> From: Guido Falsi Autocrypt: addr=mad@madpilot.net; keydata= mQENBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAG0Hkd1aWRvIEZhbHNpIDxtYWRAbWFkcGlsb3QubmV0PokBOQQTAQgAIwIbAwIeAQIXgAUL CQgHAwUVCgkICwQWAgMBBQJS79AgAhkBAAoJEBrmhg5Wy9KTc0kH/RO64ORBlTbTHaUaOj8F Je5O5NU2Pt9Cyt5ZWBRvxntr1zPTJGKRPS9ihlIfqT4ZvEngQGp57EUyFbCpI0UWasTerImM tt5WACnGmCzUTB39UXx8Oy4b1EgWeTJQ747e/F1mQLXTNa6ijRBE9fYlTb4gAkPN88/wVV9v 3PZozKLTg16ghBzHM/P7Lk8L7clPEZChX1FTa/6eSt3nvzfCuTMZbBPJF/ph+q1KyPqRgVfh tyhu5dvgMoPz/ni41IfeSrkJTD5RXzdyGR9q4Z1NYeBsLkRjC4LxKAP5KqUsvlOUjKvO1byj ApYdMarol+IGkaSk9e3zVYAJkWKjn/ni8Xa5Ag0EUxB7QQEQAKFhrDceoPdK/IHDSmoj6SQY isvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef+WE7 5M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ubeT3Xw QO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr8OEQ fOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB2i6A /xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45qfyh MiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0xpNi UilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWAdlKC NTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanCYrAg +8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNRgow3 kSuArUp6zSmJABEBAAGJAR8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCkX/qw EVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7FjfrV +dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxAlZ/7 i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+lQMZ 9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8LkQd rQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncrkBDQRPhvpdAQgAsd6mrOq1GSZw lzRscNQa9W2WB/3Tj4ON4PL2e9B+hc9lT/ny2zB3agXu5wbsXTzwxgJpQT7hNHkCSckW98h3 HRjFfhZPNCgInuUGsjcNyVguQh+/47ckhph0s7U+6B4yNuIiqQZk4mo8WgCNj1YIihVmGWEs gDOwMaajbDYZ0r1/3GkKlYjOXeUuT/WgourrSR5oZJVNA/k4X2H7M3JUr1BSc32L7BJt8M7A ntul6k17J0L8GmkvLvTUtQTO+p+DYQMna2ngD3PbAvQRcbEGnkg9ABrdEF0Wp4Gx+gGGWsyF KlHvPdMtgWAy3JsS+rQapG6LoW3yUJpwpEpA86KdBwARAQABiQEfBCgBCAAJBQJTEH0NAh0B AAoJEBrmhg5Wy9KTMZcIAMSsidGF4KpjGcKzhkNK0sEpevcelQ6DzgT7kcXuq6LQ6YOrbof2 /KPgGie9/ToFZfJXH8zE5GefqkKvHZbYssWilFvkI90F9n138kG205NB/2zlaQb74/v9ZMXJ XcipnIx+T2tOMCBgHJU41IMJmB+NfRt5A6CDytJdhWxqppsEo5jjy/7tJM1Nn47G87tAV8qV NUtzbS6zdnbHB4W2BJwCObbVv8epL3hu/L5efV2j2tSbVTmyvK/ClYMBqdtUo3uPX75GF/Ku YDCOP1BTA5zzmzp4PMVd+gmHcMgCZKY6lvcEtdi5FLI0we2kcY8ffPvM2d6MNhFsGLaVI95J 0oqJAR8EGAECAAkFAk+G+l0CGwwACgkQGuaGDlbL0pM18Qf9HTNNhu8N0ISKtmR8lgPhJuu8 9rOEa8KKEatr4fQ7gL+hmYOEqZ/yHLcPQvGxbAlLR7F0SheKvAEk4B1aFwGULPo0SzuO0d/W tVMEbGa95JTm/6mfiymWMlWf8UifD1MDKzzPR7Om0ybeoPM8S/RQTboUU1WLpwd4mg9pVJlK 0xr55GOSHNf4m7S+P1kvl3xgmEj14zVMq9yJBNWFlsQK5ciifh7sFpfuxWdEVbtgIdxpzImK LXSLA0vOroKAvxFTGBrBq3vxV6eUmaKyd5HbbWejmafY1ua5dcnew9lxpWKLdqkC27Vt0Cku +LtTY3325V+BChncwNcJJS7IMmBz6w== Message-ID: Date: Fri, 15 May 2020 13:48:05 +0200 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 49NmrM3ZYTz3DjC X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.15 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; MISSING_MIME_VERSION(2.00)[]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.15)[ip: (-8.67), ipnet: 159.69.0.0/16(-0.59), asn: 24940(-1.48), country: DE(-0.02)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-Mailman-Approved-At: Fri, 15 May 2020 13:01:34 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 11:48:21 -0000 On 15/05/20 11:47, Stefan Eßer wrote: > Am 15.05.20 um 03:12 schrieb Arne Steinkamm: >> On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote: >>> On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: >>> >>>> Kyle Evans wrote: >>>>> Hi, >>>>> >>>>> This is a heads up, given that I'm completely flipping our historical >>>>> behavior- I intend to commit this review in a couple days' time >>>>> without substantial objection: https://reviews.freebsd.org/D24596 >>>>> >>>>> With this, FreeBSD 13 will not allow read() of a directory fd, which >>>>> could have previously returned some data from the underlying >>>>> filesystem in no particular standardized format. >>>>> >>>>> This is a still-standards-compliant switch from one >>>>> implementation-defined behavior to another that's already been adopted >>>>> in various other popular kernels, to include OpenBSD, MacOS, and >>>>> Linux. >>>>> >>>>> Worth noting is that there's not really one largely-compelling reasons >>>>> to switch this after so many years (unless you find yourself that >>>>> irate when you accidentally `cat` a directory), but there are some >>>>> benefits which are briefly discussed in the commentary around the >>>>> review along with the history of the current behavior. >>>>> >>>>> This change also simplifies filesystem implementations to some extent. >>>>> >>>>> Thanks, >>>>> >>>>> Kyle Evans >>>> >>>> There is ZERO need for a spurious change at 2 days notice after 42+ years ! >>>> >>>> "cat ." as been supported since Unix V6 1978 or earlier, >>>> no problem, even occasionaly useful. >>>> >>> >>> Really? When is that occasionally useful? I've never seen anything useful >>> come out of reading a directory. >> >> It's all about files in Unix... >> >> This is true since 1972. >> >> And files can be read! >> >> How many (bad programmed) shell scripts will break when directory files can't >> be read anymore? I have no idea. > > And how many shell scripts will break if you migrate from UFS to ZFS > which does not return the same data? > > Reading a directory entry as a byte stream for low level debugging has > been the only valid use case I've seen in this thread. > > And I'm convinced that any developer going to work on that part of UFS > would consider adding debug code to provide or display that information > (or remove the error return just for local testing) a minor annoyance. > >> But I know for sure that there is no need to make this change. >> Not 1976, not 2020 nor in the future. > > There might be no need in the strict sense, but some reasons have been > provided: > > - Linux, macOS, OpenBSD do it (not a good reason in itself) > > - applications developed with Linux or macOS in mind might expect it > (and that is a valid reason, IMHO) Chiming in just to note that this is not a theoretical thing, I stumbled upon such a problem of this a little time ago: https://github.com/yarnpkg/yarn/issues/4884 -- Guido Falsi From owner-freebsd-arch@freebsd.org Fri May 15 13:14:52 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D81962F5480; Fri, 15 May 2020 13:14:52 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NpmD5RdXz3KZL; Fri, 15 May 2020 13:14:52 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id ACD331A7DC; Fri, 15 May 2020 13:14:52 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f169.google.com with SMTP id v4so1874383qte.3; Fri, 15 May 2020 06:14:52 -0700 (PDT) X-Gm-Message-State: AOAM531OB48/vUcUNo2SmbhZ4uPiuWbkyCaMJc/3fzpAzvOLQxaW4RXY PU3dIHHk6MjLsIx4s6Ydt6j0AtlDnzphGbWs4RA= X-Google-Smtp-Source: ABdhPJxIaPHlcjrzuRWHQGtahZPlCxiqJV30sYCkl/zlY3HM2OwIuz0tWonr8K+g7cmepdHrf3OPdhRH/z5Rz+Z/qQM= X-Received: by 2002:ac8:2fb9:: with SMTP id l54mr1797432qta.211.1589548492143; Fri, 15 May 2020 06:14:52 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> <35501.1589529102@critter.freebsd.dk> In-Reply-To: <35501.1589529102@critter.freebsd.dk> From: Kyle Evans Date: Fri, 15 May 2020 08:14:38 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: Poul-Henning Kamp Cc: Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 13:14:52 -0000 On Fri, May 15, 2020 at 2:51 AM Poul-Henning Kamp wrote: > > -------- > In message > , Kyle Evans writes: > >On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote: > > >Can we explore the possibility of using fsdb(8) to fulfill these needs > >in a way that you'd be comfortable with? >> > Summary: I'm perfectly fine with read(2) returning error on a > directory *under normal circumstances*, and I think it makes good > sense by protecting a lot of terminals from a lot of binary > garbage. > > But there is absolutely no reason to make it *impossible* for > a competent root to do what competent roots do. > First, apologies if my previous message had offended you -- I didn't mean for this, but as you can tell I was not well-equipped to discuss the possibilities with a seasoned veteran such as yourself. I've prepared a patch locally to update the review that both hides it off behind security.bsd.allow_read_dir (default off) and restricts it to a new PRIV_VFS_READ_DIR that *is not* granted to jailed root. I know we've already discussed this to some extent, but can you confirm that these restrictions are reasonable and acceptable for you? I've tentatively placed it in the security.bsd.* namespace because it can and has had security implications, but I'm certainly not dead-set on it staying there. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Fri May 15 14:48:30 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DBA932F74B2; Fri, 15 May 2020 14:48:30 +0000 (UTC) (envelope-from db@db.net) Received: from tfm.com (mtbaker.tfm.com [192.231.224.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.tfm.com", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NrrF1fcJz3RDP; Fri, 15 May 2020 14:48:28 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (DB-DSL.ServerNorth.com [98.124.61.131]) (authenticated bits=0) by tfm.com (8.14.4/8.14.4) with ESMTP id 04FEmHt5000390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2020 07:48:19 -0700 (PDT) Date: Fri, 15 May 2020 10:48:15 -0400 From: Diane Bruce To: "Rodney W. Grimes" Cc: Stefan =?iso-8859-1?Q?E=DFer?= , Arne Steinkamm , freebsd-arch@freebsd.org, FreeBSD Hackers Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515144815.GA8265@night.db.net> References: <202005151247.04FClhsD086497@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202005151247.04FClhsD086497@gndrsh.dnsmgr.net> X-Rspamd-Queue-Id: 49NrrF1fcJz3RDP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of db@db.net has no SPF policy when checking 192.231.224.2) smtp.mailfrom=db@db.net X-Spamd-Result: default: False [-1.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.943,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.88)[-0.879,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[db.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:10488, ipnet:192.231.224.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-0.61)[ip: (-1.59), ipnet: 192.231.224.0/22(-0.79), asn: 10488(-0.63), country: US(-0.05)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 14:48:30 -0000 On Fri, May 15, 2020 at 05:47:43AM -0700, Rodney W. Grimes wrote: > > Am 15.05.20 um 03:12 schrieb Arne Steinkamm: ... > > >>>> Worth noting is that there's not really one largely-compelling reasons > > >>>> to switch this after so many years (unless you find yourself that > > >>>> irate when you accidentally `cat` a directory), but there are some > > >>>> benefits which are briefly discussed in the commentary around the > > >>>> review along with the history of the current behavior. All I have to say on this noisy bikeshed is, let's resurrect the mkdir bug of V7 because it's tradition and the BSD way and history and stuff. (I only expect a few of you to remember this one.) Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-arch@freebsd.org Fri May 15 15:04:31 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DEF242F7AA2; Fri, 15 May 2020 15:04:31 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NsBj1nRvz3xVf; Fri, 15 May 2020 15:04:28 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5DDB7209.dip0.t-ipconnect.de [93.219.114.9]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04FF4NXr065035 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2020 17:04:27 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04FF4MZC098672; Fri, 15 May 2020 17:04:22 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04FF423p040952; Fri, 15 May 2020 17:04:12 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005151504.04FF423p040952@fire.js.berklix.net> To: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Cc: Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Fri, 15 May 2020 08:14:38 -0500." Date: Fri, 15 May 2020 17:04:02 +0200 X-Rspamd-Queue-Id: 49NsBj1nRvz3xVf X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.44 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.73)[-0.727,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.27)[0.273,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RECEIVED_SPAMHAUS_PBL(0.00)[9.114.219.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 15:04:31 -0000 Kyle Evans wrote: > On Fri, May 15, 2020 at 2:51 AM Poul-Henning Kamp wrote: > > > > -------- > > In message > > , Kyle Evans writes: > > >On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote: > > > > >Can we explore the possibility of using fsdb(8) to fulfill these needs > > >in a way that you'd be comfortable with? > >> > > Summary: I'm perfectly fine with read(2) returning error on a > > directory *under normal circumstances*, and I think it makes good > > sense by protecting a lot of terminals from a lot of binary > > garbage. > > > > But there is absolutely no reason to make it *impossible* for > > a competent root to do what competent roots do. > > > > First, apologies if my previous message had offended you -- I didn't > mean for this, but as you can tell I was not well-equipped to discuss > the possibilities with a seasoned veteran such as yourself. > > I've prepared a patch locally to update the review that both hides it > off behind security.bsd.allow_read_dir (default off) and restricts it > to a new PRIV_VFS_READ_DIR that *is not* granted to jailed root. I No. Root is Root regardless if in a jail or not. A root admin of a server in a jail needs full power without waiting days to contact other root human who owns the prison, without wasting human time of jail owner & prison owner formulating email request & considering & enabling requirement. kevans@ wasted FreeBSD time with threat of change at 2 days notice, for an issue unchanged since 1972. The rush was immature. kevans@ should retract his threat of forced urgent change, or expect core@ be asked to remove his commit bit while FreeBSD considers _un-rushed_, allowing sufficient time for all to consider options, & to warn users in RELNOTES of any potential future change. > know we've already discussed this to some extent, but can you confirm > that these restrictions are reasonable and acceptable for you? I've > tentatively placed it in the security.bsd.* namespace because it can > and has had security implications, but I'm certainly not dead-set on > it staying there. > > Thanks, > > Kyle Evans > Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-arch@freebsd.org Fri May 15 15:57:26 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A611C2F8F66 for ; Fri, 15 May 2020 15:57:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NtMm6DtBz42Qt for ; Fri, 15 May 2020 15:57:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x731.google.com with SMTP id g185so3012271qke.7 for ; Fri, 15 May 2020 08:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HFVsw8xrDbCjCjBYoo05RlgaBUbn9FgcTIAV2OIKs54=; b=JoPiXNFZKp9gLa8oZvkHl8UAxZwdWBugiJn7GhRkpF9impORES8zSmj/PkRccCRqcq SZ9ZxxtAJ3Qll8Bayt+U7Z4kKV5gEuCSCbrHZwefebsisaOL8C7jBDJR2aIYhitvUksM 8y9U1hMc5YzHUQsplNI6SRxPT8fql3u9qI8maegpOojj332JmLuVC4TktsTXR9pgLHwy 4S1rI0ZDYWZ60D5YGVt35TtMpXGXyu+cKwTJqOO2y3U5Q2ioFEm/Yy2EaG0FlfFm/o6p gtGhFUVEcByUWJqhKdsFnChvi/kL9OxIp+GDsu9lY7FEZWcef95hUlYGZm0Y9N4ne0s3 5cVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HFVsw8xrDbCjCjBYoo05RlgaBUbn9FgcTIAV2OIKs54=; b=CoR02/FHnguCYS3/g/pp7jSGTKt2FpGEjZMC3/Vk7L8S2clNABD3FJPKHHkmxVVKEo yQD6N6FF5ClNwE+bIgagkg+b5kIS4WeIeAoACdZ7fvqlKv5HBhalK5IxfrAf6PRifkit 8P6f3M1cgx/pDiF5KnK1YSsQ0njIOIHjCkPZMycyZ/k/Eh+0haKnU2Ysbi9tyShotV1A 9CKYusS8KfpzreGzNnOqVrpq6EjTO0lxEaoklfFzHNhPo0ksPWpKmG7rHdjrJIxIzMOP Y5+kcOk6mAYpaTtQ8KflfWhweRPcn/8yKvL0SnsELDwjAg7TjR8yHXLlvOBiIbuSvzZF X2gA== X-Gm-Message-State: AOAM533SJAfwlWmcfpPaYsRnF4JzqOW6rXvsVL3youxUef+3wO7O7kPH vVm4V/HJiXsxnHV8erh8So1wGXbQsDjBed3P5rFo3g== X-Google-Smtp-Source: ABdhPJzZfy7QIXi9UWVLT4yCy0VkHE/1gD4q0Bu/z3AE0bKs+3VejTmRM6fOFG0gAFv/Cf74IklClk/3fUMU1OKt45s= X-Received: by 2002:a05:620a:5bc:: with SMTP id q28mr4101296qkq.60.1589558243731; Fri, 15 May 2020 08:57:23 -0700 (PDT) MIME-Version: 1.0 References: <202005151504.04FF423p040952@fire.js.berklix.net> In-Reply-To: <202005151504.04FF423p040952@fire.js.berklix.net> From: Warner Losh Date: Fri, 15 May 2020 09:57:12 -0600 Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm X-Rspamd-Queue-Id: 49NtMm6DtBz42Qt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=JoPiXNFZ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::731) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.98 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-1.98)[ip: (-9.11), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.42), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 15:57:26 -0000 On Fri, May 15, 2020 at 9:04 AM Julian H. Stacey wrote: > kevans@ wasted FreeBSD time with threat of change at 2 days notice, > for an issue unchanged since 1972. The rush was immature. > > kevans@ should retract his threat of forced urgent change, or expect > core@ be asked to remove his commit bit while FreeBSD considers > _un-rushed_, allowing sufficient time for all to consider options, > & to warn users in RELNOTES of any potential future change. > Threats are not tolerated in this project. This hyperbolic response has gone on long enough. Please stop and treat your fellow committers with respect and a certain level of professionalism. He's done none of the nefarious things you've said (I've known about this changes for days if not weeks as he socialized it, for example). He doesn't deserve this level of grief over a proposal. It's a request for comments, not a request for abuse and nasty behaviour. This whole thread has gone toxic / hyperbolic over a non-issue. You should have stopped reading directories in 1983 when readdir was introduced because UFS broke ls, find, du, etc. At best, it's a nice debugging tool some folks don't want to lose. At worst, it causes bugs for programs that accidentally read directories (and maybe some, like grep, need some minor changes). It's not worth this much bile and venom. Warner From owner-freebsd-arch@freebsd.org Fri May 15 16:00:59 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6B8222F912A; Fri, 15 May 2020 16:00:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NtRv0WvHz42hY; Fri, 15 May 2020 16:00:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-164.local (unknown [IPv6:2601:648:8203:2990:74f6:48c0:2e0b:8148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 584441C0E4; Fri, 15 May 2020 16:00:58 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Cc: Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm References: <202005151504.04FF423p040952@fire.js.berklix.net> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Fri, 15 May 2020 09:00:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <202005151504.04FF423p040952@fire.js.berklix.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 16:00:59 -0000 On 5/15/20 8:04 AM, Julian H. Stacey wrote: > Kyle Evans wrote: >> On Fri, May 15, 2020 at 2:51 AM Poul-Henning Kamp wrote: >>> >>> -------- >>> In message >>> , Kyle Evans writes: >>>> On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote: >>> >>>> Can we explore the possibility of using fsdb(8) to fulfill these needs >>>> in a way that you'd be comfortable with? >>>> >>> Summary: I'm perfectly fine with read(2) returning error on a >>> directory *under normal circumstances*, and I think it makes good >>> sense by protecting a lot of terminals from a lot of binary >>> garbage. >>> >>> But there is absolutely no reason to make it *impossible* for >>> a competent root to do what competent roots do. >>> >> >> First, apologies if my previous message had offended you -- I didn't >> mean for this, but as you can tell I was not well-equipped to discuss >> the possibilities with a seasoned veteran such as yourself. >> >> I've prepared a patch locally to update the review that both hides it >> off behind security.bsd.allow_read_dir (default off) and restricts it >> to a new PRIV_VFS_READ_DIR that *is not* granted to jailed root. I > > No. Root is Root regardless if in a jail or not. Nope. Even a cursory read of prison_priv_check in kern_jail.c makes this abundantly clear. > kevans@ should retract his threat of forced urgent change, or expect > core@ be asked to remove his commit bit while FreeBSD considers > _un-rushed_, allowing sufficient time for all to consider options, > & to warn users in RELNOTES of any potential future change. You are free to ask core@ whatever you want, but you don't have the authority or credibility to claim that core@ will follow your wishes. I've watched many threads involving you over the past several years, and the pattern of behavior I've observed is that you are inflexible and usually just flame anyone who disagrees with your view or opinion. That may have been normal practice 20 years ago on the mailing lists when I first joined the project, but it isn't the normal practice now. The effect right now is that most other developers who mention you at all only do so to note that they ignore you due to your behavior. If you wish to have a voice that others will listen to in the future, you need to change your behavior. -- John Baldwin From owner-freebsd-arch@freebsd.org Fri May 15 16:11:30 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2C1C02F956A; Fri, 15 May 2020 16:11:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nth03KL7z43j4; Fri, 15 May 2020 16:11:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id A2F331AF18C; Fri, 15 May 2020 16:11:25 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id 04FGBPOZ044548 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 16:11:25 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id 04FGBOt2044547; Fri, 15 May 2020 16:11:24 GMT (envelope-from phk) To: "Julian H. Stacey" cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Kyle Evans , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: <202005151504.04FF423p040952@fire.js.berklix.net> From: "Poul-Henning Kamp" References: <202005151504.04FF423p040952@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44545.1589559084.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2020 16:11:24 +0000 Message-ID: <44546.1589559084@critter.freebsd.dk> X-Rspamd-Queue-Id: 49Nth03KL7z43j4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.70 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.78)[-0.776,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.97)[-0.971,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.04)[ip: (0.06), ipnet: 130.225.0.0/16(0.08), asn: 1835(0.08), country: EU(-0.01)]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 16:11:30 -0000 -------- In message <202005151504.04FF423p040952@fire.js.berklix.net>, "Julian H. S= tacey " writes: >No. Root is Root regardless if in a jail or not. No. See also: https://papers.freebsd.org/2000/phk-jails/ = -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Fri May 15 16:58:44 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ACDF72FA87E for ; Fri, 15 May 2020 16:58:44 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NvkX49Mcz46sJ; Fri, 15 May 2020 16:58:44 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 7C83A1C806; Fri, 15 May 2020 16:58:44 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f172.google.com with SMTP id f83so3204736qke.13; Fri, 15 May 2020 09:58:44 -0700 (PDT) X-Gm-Message-State: AOAM532g0pDKHsuxIkIwibIcGjLp6y6ME1H3O9+pKNXZ5Bk2lDIFiOQV sDvWgjcOQNp+ysJfyv3uOL3sW8KxO9Mt2G4MhmE= X-Google-Smtp-Source: ABdhPJx76+1zftOBLi+9PqC9yAFU1dVRrJjm++GqlGBrpFoH4u+VKConhu5MCeh3iyc81ThrFS2a2qdRVLxVbcWRTxY= X-Received: by 2002:a37:8c4:: with SMTP id 187mr4376247qki.34.1589561924140; Fri, 15 May 2020 09:58:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Fri, 15 May 2020 11:58:30 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "freebsd-arch@freebsd.org" Cc: "Rodney W. Grimes" , Poul-Henning Kamp Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 16:58:44 -0000 On Thu, May 14, 2020 at 1:26 PM Kyle Evans wrote: > > Hi, > > This is a heads up, given that I'm completely flipping our historical > behavior- I intend to commit this review in a couple days' time > without substantial objection: https://reviews.freebsd.org/D24596 > Note that the review has been updated to reflect feedback received through the course of this discussion. The current version, as of the time of writing, instead adds a security.bsd.allow_read_dir (defaulting to off) that will allow the system root (*not* jailed root) the ability to read(2) a directory if the filesystem supports it. A new priv(9), PRIV_VFS_READ_DIR has been added so that anyone interested in expanding the scope of the sysctl beyond the system root is welcome to implement a MAC policy for it. rgrimes@ and phk@ have been specifically invited to the review as representatives of those opposing the original change, but of course anyone is free to add themselves and/or simply chime in with constructive objections. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Fri May 15 18:01:35 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4562E2FC667; Fri, 15 May 2020 18:01:35 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 49Nx7163kTz4DPw; Fri, 15 May 2020 18:01:33 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04FI1Oju022407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 May 2020 14:01:27 -0400 Date: Fri, 15 May 2020 11:01:24 -0700 From: Benjamin Kaduk To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515180124.GB27494@kduck.mit.edu> References: <202005151504.04FF423p040952@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202005151504.04FF423p040952@fire.js.berklix.net> User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 49Nx7163kTz4DPw X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-5.42 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[mit.edu]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[11.28.9.18.list.dnswl.org : 127.0.11.2]; RCPT_COUNT_SEVEN(0.00)[7]; IP_SCORE(-2.92)[ip: (-9.68), ipnet: 18.9.0.0/16(-4.80), asn: 3(-0.06), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 18:01:35 -0000 On Fri, May 15, 2020 at 05:04:02PM +0200, Julian H. Stacey wrote: > > kevans@ wasted FreeBSD time with threat of change at 2 days notice, I disagree with describing the proposal as a "threat of change", and am confident that the response thus far has met the "substantial objection" threshold needed to pause the intent to commit pending further discussion/revision. I'm not replying to the other points, that others have covered already. -Ben From owner-freebsd-arch@freebsd.org Fri May 15 18:07:50 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D0F1E2FC970; Fri, 15 May 2020 18:07:50 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NxGF2wZZz4Dxv; Fri, 15 May 2020 18:07:49 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5DDB7209.dip0.t-ipconnect.de [93.219.114.9]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04FI7fEc066498 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2020 20:07:45 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04FI7eBh099847; Fri, 15 May 2020 20:07:40 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04FI7K8q045648; Fri, 15 May 2020 20:07:30 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005151807.04FI7K8q045648@fire.js.berklix.net> To: "Poul-Henning Kamp" cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Kyle Evans , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Fri, 15 May 2020 16:11:24 -0000." <44546.1589559084@critter.freebsd.dk> Date: Fri, 15 May 2020 20:07:20 +0200 X-Rspamd-Queue-Id: 49NxGF2wZZz4Dxv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.27 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.80)[-0.800,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.17)[0.168,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RECEIVED_SPAMHAUS_PBL(0.00)[9.114.219.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 18:07:50 -0000 "Poul-Henning Kamp" wrote: > -------- > In message <202005151504.04FF423p040952@fire.js.berklix.net>, "Julian H. Stacey > " writes: > > >No. Root is Root regardless if in a jail or not. > > No. Thanks, Accepting you mean: power of a root login within a jail is less. Yes I knew that, but I guess mine above was ambiguous, & more so without text restored below. I meant root the person, who has to login & fix various hosts, regardless if they are jails or not. It's already harder to work in jails; further limitation unwelcome. > > A root admin of > > a server in a jail needs full power without waiting days to contact > > other root human who owns the prison, without wasting human time > > of jail owner & prison owner formulating email request & considering > > & enabling requirement. > See also: https://papers.freebsd.org/2000/phk-jails/ Will do, thanks. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-arch@freebsd.org Fri May 15 19:58:07 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CE9192FEF2D for ; Fri, 15 May 2020 19:58:07 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NzjW54bfz4N48; Fri, 15 May 2020 19:58:07 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 9D2C51DD86; Fri, 15 May 2020 19:58:07 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f182.google.com with SMTP id m44so3043479qtm.8; Fri, 15 May 2020 12:58:07 -0700 (PDT) X-Gm-Message-State: AOAM530kCAgMhnKdmwxmN+f4TIBgyzOdldZFlgLzpcu2h8Mje9MJXXm2 TNuz3BPwDBHW0gQ+t7zurQCuo75pkPuoIMwbJg4= X-Google-Smtp-Source: ABdhPJyzHxN05qfRun2yeN2XfmsWfM51TwyFz+KUPJVs+Hq4VsMOKYxiIM0KTNzZ7YdQYtHaC5h5ZRO48v6n21+NBMM= X-Received: by 2002:ac8:5353:: with SMTP id d19mr5194528qto.310.1589572687272; Fri, 15 May 2020 12:58:07 -0700 (PDT) MIME-Version: 1.0 References: <202005151944.04FJiXmr087925@gndrsh.dnsmgr.net> In-Reply-To: <202005151944.04FJiXmr087925@gndrsh.dnsmgr.net> From: Kyle Evans Date: Fri, 15 May 2020 14:57:53 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Rodney W. Grimes" Cc: "freebsd-arch@freebsd.org" , Poul-Henning Kamp Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 19:58:07 -0000 On Fri, May 15, 2020 at 2:44 PM Rodney W. Grimes wrote: > > > On Thu, May 14, 2020 at 1:26 PM Kyle Evans wrote: > > > > > > Hi, > > > > > > This is a heads up, given that I'm completely flipping our historical > > > behavior- I intend to commit this review in a couple days' time > > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > > > > Note that the review has been updated to reflect feedback received > > through the course of this discussion. The current version, as of the > > time of writing, instead adds a security.bsd.allow_read_dir > > (defaulting to off) that will allow the system root (*not* jailed > > root) the ability to read(2) a directory if the filesystem supports > > it. A new priv(9), PRIV_VFS_READ_DIR has been added so that anyone > > interested in expanding the scope of the sysctl beyond the system root > > is welcome to implement a MAC policy for it. > > > > rgrimes@ and phk@ have been specifically invited to the review as > > representatives of those opposing the original change, but of course > > anyone is free to add themselves and/or simply chime in with > > constructive objections. > > I did not oppose the change, just asked that the change be knobbed > so that the few rare ones of us that do use this ability do not > have to jump through hoops when we need it to fix a problem. > Apologies, I did not intend to misrepresent your position -- I had interpreted your post as "objection with a path to acceptance" and followed it to that end since I was providing a revised version that aimed to also appeal to your criteria. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Fri May 15 20:01:04 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 296D62FF1CD; Fri, 15 May 2020 20:01:04 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nzms6cBkz4NS2; Fri, 15 May 2020 20:01:01 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id ZgVsjkptQ62brZgVujvK3u; Fri, 15 May 2020 14:00:59 -0600 X-Authority-Analysis: v=2.3 cv=LKf9vKe9 c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=Ikt0M2cxAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=PX1mssMcXtx11Gsav7AA:9 a=CjuIK1q_8ugA:10 a=iYm7J9qDpiSF5xNCBZUT:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 2985E452; Fri, 15 May 2020 13:00:56 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 04FK0tr6006519; Fri, 15 May 2020 13:00:55 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 04FK0tjk006516; Fri, 15 May 2020 13:00:55 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202005152000.04FK0tjk006516@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Julian H. Stacey" cc: Kyle Evans , "freebsd-arch@freebsd.org" , hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: <202005142017.04EKH0aA093503@fire.js.berklix.net> References: <202005142017.04EKH0aA093503@fire.js.berklix.net> Comments: In-reply-to "Julian H. Stacey" message dated "Thu, 14 May 2020 22:17:00 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 May 2020 13:00:55 -0700 X-CMAE-Envelope: MS4wfGZ28CIBinMWwKmXrdF2FyXcoe4/VZsiwnx1FFEs7C87HEfX03+qKg3AV+MWgRQRRvILkgNM8DGbJ53QimCl7sUx/XBqTvvVmH68HiOSOZTQ/yWE8Fk8 lhBGHwAzdWG5qu+9yMYGSepZh7ZU2ZAq3wd9nCrHpg7qQ4mRwQrOTHXt6dRhjoGTPUTbvPMibEfnBZkXc3sGPZLZQjrBEWZKLvmH6fusM0xzX0b5dYPjWe/5 /THMhxJZUBuzwqqLNsFSJ1BNiaKkJbI8twi0TiZGTzM= X-Rspamd-Queue-Id: 49Nzms6cBkz4NS2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.9) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.24 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[9.134.59.64.rep.mailspike.net : 127.0.0.18]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MV_CASE(0.50)[]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.54)[ip: (-6.74), ipnet: 64.59.128.0/20(-3.30), asn: 6327(-2.58), country: CA(-0.09)]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[9.134.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 20:01:04 -0000 In message <202005142017.04EKH0aA093503@fire.js.berklix.net>, "Julian H. Stacey " writes: > Kyle Evans wrote: > > Hi, > > > > This is a heads up, given that I'm completely flipping our historical > > behavior- I intend to commit this review in a couple days' time > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > could have previously returned some data from the underlying > > filesystem in no particular standardized format. > > > > This is a still-standards-compliant switch from one > > implementation-defined behavior to another that's already been adopted > > in various other popular kernels, to include OpenBSD, MacOS, and > > Linux. > > > > Worth noting is that there's not really one largely-compelling reasons > > to switch this after so many years (unless you find yourself that > > irate when you accidentally `cat` a directory), but there are some > > benefits which are briefly discussed in the commentary around the > > review along with the history of the current behavior. > > > > This change also simplifies filesystem implementations to some extent. > > > > Thanks, > > > > Kyle Evans > > There is ZERO need for a spurious change at 2 days notice after 42+ years ! It's been 42 or more years since this bug was introduced. Let's just fix it now instead of agonizing over it. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Fri May 15 21:08:42 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1FC8B2D9A34; Fri, 15 May 2020 21:08:42 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P1Gw5Y3zz4Sct; Fri, 15 May 2020 21:08:40 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id ZhZKjwTUmYYpxZhZLjBeTm; Fri, 15 May 2020 15:08:38 -0600 X-Authority-Analysis: v=2.3 cv=OubUNx3t c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=eYNpW-z5zCPCEBFOaAsA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id B5CD059F; Fri, 15 May 2020 14:08:33 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 04FL8XgW007133; Fri, 15 May 2020 14:08:33 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 04FL8WeJ007130; Fri, 15 May 2020 14:08:32 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202005152108.04FL8WeJ007130@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Kyle Evans cc: Poul-Henning Kamp , Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> Comments: In-reply-to Kyle Evans message dated "Fri, 15 May 2020 00:10:35 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 May 2020 14:08:32 -0700 X-CMAE-Envelope: MS4wfMifuAH4ZttWaMWykk8z+rExp2qTh0SdQv6mZtQHLZXc03pAlJ8GbWIcYAIPeA5Kax9JvLIOoGsQKY0WBq1EMPtQtC3f8Pr+5HqVs/UNVB9yjAF6++Va GWcVHJ/GHFTjynhkRgI1H3Q5ZLg4VQWm/IC1uo5/y2VcTIFoCbffpqi7v+d7gM4oR+yf+fKUhmiyYdZ0w1CZ+a0XM3ErVFQ7VJ3v8me8QU9ryqkAYDj7omgW dpkJDt/41E+l9JeHn3yHcSWJxzSuHqdEyyUkdd4dAF4aEUuOH3YUEWhd/0K+NjMQU2IZN0qNoaLLKsa0DmKp9KaZCqKhfvArjmk4kEqzsOI= X-Rspamd-Queue-Id: 49P1Gw5Y3zz4Sct X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.137) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.18 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCPT_COUNT_FIVE(0.00)[6]; REPLYTO_EQ_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.48)[ip: (-6.44), ipnet: 64.59.128.0/20(-3.30), asn: 6327(-2.58), country: CA(-0.09)]; RCVD_IN_DNSWL_LOW(-0.10)[137.136.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 21:08:42 -0000 In message , Kyle Evans writes: > On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote: > > > > -------- > > In message com> > > , Alan Somers writes: > > > > >Really? When is that occasionally useful? I've never seen anything usefu > l > > >come out of reading a directory. > > > > Two things I have done over the years: > > > > Figure out which filenames prevent a enormous but sparse directory > > from being compacted. > > > > Figure out which control characters were in a filename. > > > > Can we explore the possibility of using fsdb(8) to fulfill these needs > in a way that you'd be comfortable with? I am thoroughly motivated and > willing to do what I can to find a good path forward. We could add a I'd like to see a good business case before a developer spends their valuable time to fulfill a some function few if any people might use. Those objecting to this should demonstrate how they currently use read()ing directories. Otherwise IMO it's a waste of your time. > sysctl and remove the functionality from other filesystems that aren't > necessarily providing useful information and likely haven't been > audited for similar disclosures to > https://www.freebsd.org/security/advisories/FreeBSD-SA-19:10.ufs.asc > that may be exacerbated by read(2) on a dirfd, but I'd like to see if > there's any compromise that we can make where the compromise on my > side is that I have to put in the effort to otherwise enable presented > valid use-cases in an agreeable manner. > > Is there anything that I, as a developer that knows very little about > UFS and even less when compared to someone such as yourself, can do to > facilitate making this as easy as possible with the tooling otherwise > available? Again, I fail to see the reason why. What purpose would read()ing a directory serve? > > Looking at fsdb(8) briefly on this UFS partition I just spun up, it > seems as a somewhat low-hanging fruit that we could (in some/many > cases) infer a disk device from a standard directory/file path and > prompt for confirmation based on that, opening up to the proper inode, > even, as an example (wording would differ, and apologies for the > formatting): > > root@shiva:/mnt# stat etc > 682 12928 drwxr-xr-x 2 root wheel 26456 512 "May 14 23:58:27 2020" > "May 14 23:58:27 2020" "May 14 23:58:27 2020" "May 14 23:58:27 2020" > 32768 8 0 etc > > root@shiva:/mnt# fsdb etc > etc is not a disk device, but is mounted from /dev/md1. Use /dev/md1? [yn] y > ** /dev/md1 (NO WRITE) > Editing file system `/dev/md1' > Last Mounted on /mnt > current inode: directory > I=12928 MODE=40755 SIZE=512 > BTIME=May 14 23:58:27 2020 [611088000 nsec] > MTIME=May 14 23:58:27 2020 [614391000 nsec] > CTIME=May 14 23:58:27 2020 [614391000 nsec] > ATIME=May 14 23:58:27 2020 [614391000 nsec] > OWNER=root GRP=wheel LINKCNT=2 FLAGS=0 BLKCNT=8 GEN=a15cce24 > > fsdb (inum: 12928)> ls > slot 0 off 0 ino 12928 reclen 12: directory, `.' > slot 1 off 12 ino 2 reclen 500: directory, `..' > > fsdb (inum: 12928)> A print in hex command possibly. Would make more sense than reading a directory in the raw. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Fri May 15 21:22:52 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D928F2DA151; Fri, 15 May 2020 21:22:52 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P1bH2b1Hz4TYq; Fri, 15 May 2020 21:22:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id Zhn5jwZ05YYpxZhn7jBhiM; Fri, 15 May 2020 15:22:49 -0600 X-Authority-Analysis: v=2.3 cv=OubUNx3t c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YwyvHg-N9EvwjEekwyUA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 61630537; Fri, 15 May 2020 14:22:47 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 04FLMluj007217; Fri, 15 May 2020 14:22:47 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 04FLMkd8007214; Fri, 15 May 2020 14:22:47 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202005152122.04FLMkd8007214@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Poul-Henning Kamp" cc: Kyle Evans , Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: <35501.1589529102@critter.freebsd.dk> References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> <35501.1589529102@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Fri, 15 May 2020 07:51:42 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 May 2020 14:22:46 -0700 X-CMAE-Envelope: MS4wfANA8adDSzJTRtipvrqWGMZHDRYx3BCsTco9NeKiJ3KEv/lhqw9bNC2nGGsGcAKNseIzPiwBJyL7ZKsLkQEPaweYDzz4hN/ivILh2Mc3xZtnVHGCZ6nI hNhfy+/jEJzrLBp+H5WygSXJFt3YJyMuC8M7byI1WUrLowynaPDKOfs0Px9U7yo9vETsaucCPh/3gFcrrBL0rrDbX8fbwJMxVprv1AlhHo1ysKJj6ad0awvE trlbbIjaRzo+mApJaGp0W21ANIG/A/FITZq7usA2IRMC0u5z4k/3eJDZ1weYWdivltAv/7srEsRRuwDdftF+DvbwtZH3DahpRDTccAxtgsE= X-Rspamd-Queue-Id: 49P1bH2b1Hz4TYq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.138) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.23 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCPT_COUNT_FIVE(0.00)[6]; REPLYTO_EQ_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[138.136.59.64.rep.mailspike.net : 127.0.0.17]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; R_SPF_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_IN_DNSWL_LOW(-0.10)[138.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.53)[ip: (-6.66), ipnet: 64.59.128.0/20(-3.30), asn: 6327(-2.58), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 21:22:52 -0000 In message <35501.1589529102@critter.freebsd.dk>, "Poul-Henning Kamp" writes: > -------- > In message m> > , Kyle Evans writes: > >On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote > : > > >Can we explore the possibility of using fsdb(8) to fulfill these needs > >in a way that you'd be comfortable with? > > First, I am perfectly comfortable with fsdb(8), but in both the two > scenarios it was much less timeconsuming to do: > > strings < /some/directory | head > > Which immediately gives you the first filenames in the directory, > without waiting for ls(1) to read the entire directory, which in > this case was well north of 100MB. > > In the other case > > hexdump -C < /some/directory | grep part_of_suspect_filename > > gave me the answer faster than I could have started fsdb, it gave > me the answer in convenient hexadecimal, and besides it was not > a UFS filesystem. > > Second, one of the major reasons, probably about 3/4 of the total > reason I ended up in FreeBSD, was because of some utterly shit > experiences with commercial operating systems, where I had been in > a tight corner at 00-dark o'clock, and run straight into something > some idiot of at the vendor thought root should not be able to do > "for their own safety". > > This change falls right into that category: If root wants to hexdump > a directory, an entire bloody disk, or even if root wants to go > and do binary surgery on a mounted file system with a hex-editor, > root should be able to do that. > > She may have to `sysctl kern.warranty_voided=999` first, to disable > *under normal circumstances* reasonable and sensible protections. > > I'm perfectly fine with that: We do not want to make being root a > minefield, and I myself put the ability to munge mounted filesystems > under such a interlock in GEOM. > > But we should not make it *impossible* to do these things, and in > particular, we should not make them require a reboot, because ten > times out of nine, when you find yourself doing this kind of shit, > it is usually because you're pretty sure everything is lost if you > reboot. > > Summary: I'm perfectly fine with read(2) returning error on a > directory *under normal circumstances*, and I think it makes good > sense by protecting a lot of terminals from a lot of binary > garbage. > > But there is absolutely no reason to make it *impossible* for > a competent root to do what competent roots do. A kern.geom.debugflags-like thing might help but the complexity the code remains. Kyle's patch reduces complexity to a degree. A debugflags sysctl won't, it will add a little complexity. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Fri May 15 21:24:38 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D23842DA536; Fri, 15 May 2020 21:24:38 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P1dK4rsBz4Trd; Fri, 15 May 2020 21:24:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id ZholjRFzcng7KZhonjeaji; Fri, 15 May 2020 15:24:35 -0600 X-Authority-Analysis: v=2.3 cv=ecemg4MH c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=NRF7K_vUAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=gs-f4NG6evmkO6fCgWAA:9 a=CjuIK1q_8ugA:10 a=-TUkS2ffhQBfG7ohTqvO:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 87F985BB; Fri, 15 May 2020 14:24:31 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 04FLOVL6007256; Fri, 15 May 2020 14:24:31 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 04FLOUNq007253; Fri, 15 May 2020 14:24:31 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202005152124.04FLOUNq007253@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Warner Losh cc: "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: References: <202005151504.04FF423p040952@fire.js.berklix.net> Comments: In-reply-to Warner Losh message dated "Fri, 15 May 2020 09:57:12 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 May 2020 14:24:30 -0700 X-CMAE-Envelope: MS4wfF/LejAwk4X4h+VQDh8s8Y7tD3xRWTO4z/Uh3AqNJMcNt0bNQHxOinQsokyrYz/npQ/hrjg67pmCMVMr5Y6+5g+nOlpTCii7Z8IV/mWNDds0jCWlaYei 0BAiFpRB3J6D0PTF64ws2D7cba+/ISku9/Xfk2yANKMPHnxfCZhvxYLW0K7MtmPehKRvv6fOYgR75HJ+6YhClBPKWpVCOzWkXbKzC8nowAFBTAoAJN67PrKV MT5+tj0NdU9j/fChbiHbBYzEVRk5o5g/3kiPBQ4+aUwrDsT3CM0Im9BTwXKpvLHBGDj7RTZlWN9w6WOQYEqPijSr93skOrhdBBK262b3RVkZqId8Js6cJSKx 5PRIzP0T1eCfNdObuGNmfNqH+mMFKR3F/dPPwBckmkZAmYB2oFI= X-Rspamd-Queue-Id: 49P1dK4rsBz4Trd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.12) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.25 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RWL_MAILSPIKE_GOOD(0.00)[12.134.59.64.rep.mailspike.net : 127.0.0.18]; REPLYTO_EQ_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_SEVEN(0.00)[8]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.55)[ip: (-6.77), ipnet: 64.59.128.0/20(-3.30), asn: 6327(-2.58), country: CA(-0.09)]; RCVD_IN_DNSWL_LOW(-0.10)[12.134.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 21:24:38 -0000 In message , Warner Losh writes: > On Fri, May 15, 2020 at 9:04 AM Julian H. Stacey wrote: > > > kevans@ wasted FreeBSD time with threat of change at 2 days notice, > > for an issue unchanged since 1972. The rush was immature. > > > > kevans@ should retract his threat of forced urgent change, or expect > > core@ be asked to remove his commit bit while FreeBSD considers > > _un-rushed_, allowing sufficient time for all to consider options, > > & to warn users in RELNOTES of any potential future change. > > > > Threats are not tolerated in this project. This hyperbolic response has > gone on long enough. Please stop and treat your fellow committers with > respect and a certain level of professionalism. He's done none of the > nefarious things you've said (I've known about this changes for days if not > weeks as he socialized it, for example). He doesn't deserve this level of > grief over a proposal. It's a request for comments, not a request for abuse > and nasty behaviour. > > This whole thread has gone toxic / hyperbolic over a non-issue. You should > have stopped reading directories in 1983 when readdir was introduced > because UFS broke ls, find, du, etc. At best, it's a nice debugging tool > some folks don't want to lose. At worst, it causes bugs for programs that > accidentally read directories (and maybe some, like grep, need some minor > changes). It's not worth this much bile and venom. +1 -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Fri May 15 22:00:00 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CB9BE2DB293; Fri, 15 May 2020 22:00:00 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P2Q73RFVz4WSM; Fri, 15 May 2020 21:59:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f179.google.com with SMTP id d191so3562317oib.12; Fri, 15 May 2020 14:59:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Sb8oJ7xDyF38Y28ZipIiwHUTLj2w6/8R0/6W1llCvug=; b=Iawj8VeeJRuwpPHyUTg5MsxsA75+YHboRuH6nX6GWofdBdA2p3BZg1ntCGxs+UNHwa JavJuLmugIXSm9KuTkLZDuLUq9I0qIhEdDR9BVimLE39l4qBB4VDAQDLK24LCwlYs2Ub TXkY6fxXOFbmgW/EP5lKDrUmNFfAxGC8DmNwcwcmgZzwFuY62eA7u534b4lgV5XFmHuQ 97uB9Iv0paGmi0AGUUuUDhw8jbgC0pkRO9A84BUWByUxBU13ZD3Ne8HLYghbNCCDD7YI +V7RPBcBt+zrfK0pQQ6jcoRUX6tusAwoNkdEz/Gy5eiK6gqx5ZL8UwzDq52yFAlzSsI5 GLMw== X-Gm-Message-State: AOAM532nUdQX++oexXJCvTXIszfVVRhLd2lCrgr3rz6KIcRQZRSPR7U8 ntEWUAb+OPVlLQFHCNot5GGHa1/AgzWnZlwBqMQ7OKvD X-Google-Smtp-Source: ABdhPJzuNX5kn5vuPZ7DRdrkesxKZILmrAnp+nTKIx5QciZPJ5VsYnXrLl12H7RpPwumWmikDOoMZ6FQnns/jbtDu6w= X-Received: by 2002:aca:bf09:: with SMTP id p9mr3367994oif.55.1589579998133; Fri, 15 May 2020 14:59:58 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> <202005152108.04FL8WeJ007130@slippy.cwsent.com> In-Reply-To: <202005152108.04FL8WeJ007130@slippy.cwsent.com> From: Alan Somers Date: Fri, 15 May 2020 15:59:46 -0600 Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: Cy Schubert Cc: Kyle Evans , Poul-Henning Kamp , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 49P2Q73RFVz4WSM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.179 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.20 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[179.167.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.21)[ip: (-0.21), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.42), country: US(-0.05)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[179.167.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 22:00:00 -0000 On Fri, May 15, 2020 at 3:08 PM Cy Schubert wrote: > In message > om> > , Kyle Evans writes: > > On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp > wrote: > > > > > > -------- > > > In message > > com> > > > , Alan Somers writes: > > > > > > >Really? When is that occasionally useful? I've never seen anything > usefu > > l > > > >come out of reading a directory. > > > > > > Two things I have done over the years: > > > > > > Figure out which filenames prevent a enormous but sparse directory > > > from being compacted. > > > > > > Figure out which control characters were in a filename. > > > > > > > Can we explore the possibility of using fsdb(8) to fulfill these needs > > in a way that you'd be comfortable with? I am thoroughly motivated and > > willing to do what I can to find a good path forward. We could add a > > I'd like to see a good business case before a developer spends their > valuable time to fulfill a some function few if any people might use. > Those > objecting to this should demonstrate how they currently use read()ing > directories. Otherwise IMO it's a waste of your time. > +1. The suggested use cases are marginal, and would be better served by fsdb. Disallowing reads on directories makes sense. Kyle ought to unconditionally disable until a real need is proven. -Alan From owner-freebsd-arch@freebsd.org Fri May 15 23:06:53 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B2732DCE40; Fri, 15 May 2020 23:06:53 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P3v90485z4bB9; Fri, 15 May 2020 23:06:44 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C9E4.dip0.t-ipconnect.de [46.82.201.228]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04FN6c2Q069463 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 May 2020 01:06:43 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04FN6cHl001735; Sat, 16 May 2020 01:06:38 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04FN6Irf049862; Sat, 16 May 2020 01:06:28 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005152306.04FN6Irf049862@fire.js.berklix.net> To: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" cc: Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Fri, 15 May 2020 09:00:56 -0700." Date: Sat, 16 May 2020 01:06:18 +0200 X-Rspamd-Queue-Id: 49P3v90485z4bB9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.31 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.77)[-0.770,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.18)[0.180,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RECEIVED_SPAMHAUS_PBL(0.00)[228.201.82.46.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 23:06:53 -0000 > From: John Baldwin > I've watched many threads involving you over the past several years, Flame bait declined. > From: Warner Losh > It's not worth this much bile and venom. Friction is risked when ever code is rammed too fast. Seen it before. Self discipline with delay can avoid friction. Wider review & generous time scales can reduce friction. Enforced commit review policy could avoid friction. It's best to criticise ideas, not people. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-arch@freebsd.org Fri May 15 15:06:55 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 126252F7C96; Fri, 15 May 2020 15:06:55 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mail.steinkamm.com (mail.steinkamm.com [194.127.175.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "steinkamm.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NsFS5Ws5z3xr0; Fri, 15 May 2020 15:06:52 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from trajan.stk.cx (trajan.stk.cx [10.8.8.110]) by basis.steinkamm.com (8.15.2/8.15.2) with ESMTPS id 04FF6dt3014096 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 15 May 2020 17:06:39 +0200 (CEST) (envelope-from arne@steinkamm.com) Received: from trajan.stk.cx (localhost [127.0.0.1]) by trajan.stk.cx (8.15.2/8.15.2) with ESMTPS id 04FF6cxw065070 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 17:06:38 +0200 (CEST) (envelope-from arne@trajan.stk.cx) Received: (from arne@localhost) by trajan.stk.cx (8.15.2/8.15.2/Submit) id 04FF6RIZ064487; Fri, 15 May 2020 17:06:27 +0200 (CEST) (envelope-from arne) Date: Fri, 15 May 2020 17:06:27 +0200 From: Arne Steinkamm To: Diane Bruce Cc: "Rodney W. Grimes" , Arne Steinkamm , FreeBSD Hackers , freebsd-arch@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515150627.GY82984@trajan.stk.cx> Reply-To: arne@Steinkamm.COM References: <202005151247.04FClhsD086497@gndrsh.dnsmgr.net> <20200515144815.GA8265@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200515144815.GA8265@night.db.net> User-Agent: Mutt@Trajan/1.12.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on basis.steinkamm.com X-Rspamd-Queue-Id: 49NsFS5Ws5z3xr0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of arne@Steinkamm.COM has no SPF policy when checking 194.127.175.194) smtp.mailfrom=arne@Steinkamm.COM X-Spamd-Result: default: False [0.82 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[arne@Steinkamm.COM]; NEURAL_HAM_MEDIUM(-0.47)[-0.470,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.02)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[Steinkamm.COM]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.10)[0.098,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:34646, ipnet:194.127.175.0/24, country:DE]; FROM_NEQ_ENVFROM(0.00)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; RCVD_TLS_ALL(0.00)[] X-Mailman-Approved-At: Sat, 16 May 2020 07:22:55 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 15:06:55 -0000 On Fri, May 15, 2020 at 10:48:15AM -0400, Diane Bruce wrote: > All I have to say on this noisy bikeshed is, let's resurrect the mkdir > bug of V7 because it's tradition and the BSD way and history and stuff. > (I only expect a few of you to remember this one.) Oh, this "bug" was alive until Sys V 3.2 times... Implementing mkdir as library function without a syscall wasn't a good idea. ken and dmr saw no reason to implement mkdir as atomic operation. So it was easy, even with a shell script, to jump between the mknod(2) and the chown(2) to replace the directory node with a symlink to /etc/passwd. This was from a todays point of view a stupid mistake. Reading a directory node is lightyears away from "a stupid mistake". Make it switchable with a sysctl switch... would be the best of both worlds. .//. Arne -- Arne Steinkamm | Home: Mail: arnesteinkammcom Tel.: +49.89.21031004 | Gröbenbachweg 13, 82178 Puchheim, GERMANY From owner-freebsd-arch@freebsd.org Fri May 15 17:34:15 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1FA442FB5AA for ; Fri, 15 May 2020 17:34:15 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NwWT609lz49lW for ; Fri, 15 May 2020 17:34:13 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-ot1-x32c.google.com with SMTP id z3so860220otp.9 for ; Fri, 15 May 2020 10:34:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dgm9xRRsSYlBUD34jO9rOYB7RhKEiYIqFoVgqBRIL/I=; b=sgxiWLQGqcgKiYrUguExSRjNLc1lCQn9iAzA7dfavua65Vs3vYGkyviTsMOkkGvRlJ LWIbuVMcsXhr5dvkf3A1wSoK3g5HSculobHrx8iO+ArVHSVMszyoaD9R4JXggTW59m0p TKj9H8VnCDthEBmcAkM0sgHPpflnr66Tb07whAX3mQI+KdaIgCkMC4gT8A1bfUWyJRYN TcNkM7jt5WtXdppXKRBB76ENp3nrwDH3oFPI7a25ubiouvkV2iHwC3GrNqLenoFyeYXc pHNsFtWE3/YcPY8D03i+Y9bZfyMSC5NbibIGevseAKHq1BI256Hs88q3wHK95lO9qX7a aRGw== X-Gm-Message-State: AOAM530JinFLEoLsYNfgZfehnu1icE5qpFo324yvXZzdCvdB7tNLgaE7 5P1CD4prHwFMEiVHtljwy9UB+A== X-Google-Smtp-Source: ABdhPJz5hgUejUUzb1pcoxSVhKQxjaomBE2OKs19nA3EHrpUnt+rp2680Mg4eEwfQctoS3OvgLtvVg== X-Received: by 2002:a05:6830:1d88:: with SMTP id y8mr3265310oti.255.1589564052280; Fri, 15 May 2020 10:34:12 -0700 (PDT) Received: from [172.21.0.25] (66-196-7-151.dyn.grandenetworks.net. [66.196.7.151]) by smtp.gmail.com with ESMTPSA id w14sm742888oou.46.2020.05.15.10.34.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2020 10:34:11 -0700 (PDT) From: Jim Thompson Message-Id: <9C0CCC6D-BA3A-4068-BC3B-5B40E7C668E1@netgate.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [HEADSUP] Disallowing read() of a directory fd Date: Fri, 15 May 2020 12:34:10 -0500 In-Reply-To: <35501.1589529102@critter.freebsd.dk> Cc: Kyle Evans , Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" To: Poul-Henning Kamp References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> <35501.1589529102@critter.freebsd.dk> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49NwWT609lz49lW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.26 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[netgate.com:s=google]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[netgate.com:+]; DMARC_POLICY_ALLOW(-0.50)[netgate.com,quarantine]; RCVD_IN_DNSWL_NONE(0.00)[c.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-1.76)[ip: (-7.99), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.42), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Mailman-Approved-At: Sat, 16 May 2020 07:23:44 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 17:34:15 -0000 > On May 15, 2020, at 2:51 AM, Poul-Henning Kamp = wrote: >=20 > Summary: I'm perfectly fine with read(2) returning error on a > directory *under normal circumstances*, and I think it makes good > sense by protecting a lot of terminals from a lot of binary > garbage. >=20 > But there is absolutely no reason to make it *impossible* for > a competent root to do what competent roots do. In the large, I=E2=80=99m in agreement that read(2) on a directory = should work, at least for if (suser()), but the last sentence here would = allow root to write(2) a directory, too, and that hasn=E2=80=99t been = true for Unix for over 40 years, if ever. Jim From owner-freebsd-arch@freebsd.org Fri May 15 19:44:37 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0235A2FEACA for ; Fri, 15 May 2020 19:44:37 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49NzPw4jS3z4Lyx; Fri, 15 May 2020 19:44:36 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 04FJiYm6087926; Fri, 15 May 2020 12:44:34 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 04FJiXmr087925; Fri, 15 May 2020 12:44:33 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <202005151944.04FJiXmr087925@gndrsh.dnsmgr.net> Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-Reply-To: To: Kyle Evans Date: Fri, 15 May 2020 12:44:33 -0700 (PDT) CC: "freebsd-arch@freebsd.org" , "Rodney W. Grimes" , Poul-Henning Kamp Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49NzPw4jS3z4Lyx X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.97 / 15.00]; NEURAL_HAM_MEDIUM(-0.97)[-0.970,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-Mailman-Approved-At: Sat, 16 May 2020 07:55:35 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 19:44:37 -0000 > On Thu, May 14, 2020 at 1:26 PM Kyle Evans wrote: > > > > Hi, > > > > This is a heads up, given that I'm completely flipping our historical > > behavior- I intend to commit this review in a couple days' time > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > Note that the review has been updated to reflect feedback received > through the course of this discussion. The current version, as of the > time of writing, instead adds a security.bsd.allow_read_dir > (defaulting to off) that will allow the system root (*not* jailed > root) the ability to read(2) a directory if the filesystem supports > it. A new priv(9), PRIV_VFS_READ_DIR has been added so that anyone > interested in expanding the scope of the sysctl beyond the system root > is welcome to implement a MAC policy for it. > > rgrimes@ and phk@ have been specifically invited to the review as > representatives of those opposing the original change, but of course > anyone is free to add themselves and/or simply chime in with > constructive objections. I did not oppose the change, just asked that the change be knobbed so that the few rare ones of us that do use this ability do not have to jump through hoops when we need it to fix a problem. Everyone should remeber just because you do not find it useful does not mean it is not useful functionality. Remember the mantra, methods, not policy. This is a policy change. > Thanks, > Kyle Evans Regards, -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Fri May 15 20:25:45 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 40C102FFF68; Fri, 15 May 2020 20:25:45 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mail.steinkamm.com (mail.steinkamm.com [194.127.175.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "steinkamm.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P0KN0Hq5z4QgV; Fri, 15 May 2020 20:25:43 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from trajan.stk.cx (trajan.stk.cx [10.8.8.110]) by basis.steinkamm.com (8.15.2/8.15.2) with ESMTPS id 04FKPSbm017556 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 15 May 2020 22:25:28 +0200 (CEST) (envelope-from arne@steinkamm.com) Received: from trajan.stk.cx (localhost [127.0.0.1]) by trajan.stk.cx (8.15.2/8.15.2) with ESMTPS id 04FKPSZG083040 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 22:25:28 +0200 (CEST) (envelope-from arne@trajan.stk.cx) Received: (from arne@localhost) by trajan.stk.cx (8.15.2/8.15.2/Submit) id 04FKPQVj082575; Fri, 15 May 2020 22:25:26 +0200 (CEST) (envelope-from arne) Date: Fri, 15 May 2020 22:25:26 +0200 From: Arne Steinkamm To: Cy Schubert Cc: "Julian H. Stacey" , Kyle Evans , "freebsd-arch@freebsd.org" , hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515202526.GZ82984@trajan.stk.cx> Reply-To: arne@Steinkamm.COM References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <202005152000.04FK0tjk006516@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202005152000.04FK0tjk006516@slippy.cwsent.com> User-Agent: Mutt@Trajan/1.12.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on basis.steinkamm.com X-Rspamd-Queue-Id: 49P0KN0Hq5z4QgV X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of arne@Steinkamm.COM has no SPF policy when checking 194.127.175.194) smtp.mailfrom=arne@Steinkamm.COM X-Spamd-Result: default: False [1.51 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[arne@Steinkamm.COM]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.51)[-0.511,0]; IP_SCORE(-0.00)[country: DE(-0.02)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[Steinkamm.COM]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.82)[0.822,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:34646, ipnet:194.127.175.0/24, country:DE]; FROM_NEQ_ENVFROM(0.00)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; RCVD_TLS_ALL(0.00)[] X-Mailman-Approved-At: Sat, 16 May 2020 07:55:46 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 20:25:45 -0000 On Fri, May 15, 2020 at 01:00:55PM -0700, Cy Schubert wrote: > It's been 42 or more years since this bug was introduced. Let's just fix it > now instead of agonizing over it. I didn't want to add something as everything is said, but this sentence is a little bit to provocative. Everything is a file describes one of the defining features of Unix. Calling this defining feature of Unix a bug shows to me that the ideas behind Unix got lost in the FreeBSD universe too... .//. Arne -- Arne Steinkamm | Home: Mail: arnesteinkammcom From owner-freebsd-arch@freebsd.org Fri May 15 23:20:38 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 59D8D2DD449 for ; Fri, 15 May 2020 23:20:38 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P4C96njqz4bxn; Fri, 15 May 2020 23:20:37 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id 3CDD113E42; Fri, 15 May 2020 23:20:37 +0000 (UTC) Date: Fri, 15 May 2020 23:20:36 +0000 From: Mark Linimon To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515232035.GC516@lonesome.com> References: <202005152306.04FN6Irf049862@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202005152306.04FN6Irf049862@fire.js.berklix.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 49P4C96njqz4bxn X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of linimon@lonesome.com has no SPF policy when checking 18.222.6.11) smtp.mailfrom=linimon@lonesome.com X-Spamd-Result: default: False [-0.75 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.868,0]; IP_SCORE(-0.15)[ip: (0.04), ipnet: 18.220.0.0/14(0.21), asn: 16509(-0.94), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lonesome.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; NEURAL_HAM_LONG(-0.43)[-0.434,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[11.6.222.18.list.dnswl.org : 127.0.5.2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:18.220.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Sat, 16 May 2020 07:56:00 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 23:20:38 -0000 On Sat, May 16, 2020 at 01:06:18AM +0200, Julian H. Stacey wrote: > > From: John Baldwin > > I've watched many threads involving you over the past several years, > > Flame bait declined. I am going to side with jhb here. Your commonly-relied-upon tactic of "making demands" has become utterly tiresome. Not only are you yourself, as an individual contributor, in no position to make demands: making demands has no place in a cooperative volunteer project such as this, whatsoever. If that was the way things worked in the old days, well, then that was a Bug, not a Feature. I personally gave up attempting to work with you years ago. I only type these keystrokes in the hope that *something* might change. I offer this *regardless* of whether I agree with what you said, or not. mcl From owner-freebsd-arch@freebsd.org Sat May 16 11:42:02 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 916B22F00BE for ; Sat, 16 May 2020 11:42:02 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PNfd2bxyz4QjM; Sat, 16 May 2020 11:42:00 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C9E4.dip0.t-ipconnect.de [46.82.201.228]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04GBfr1c076994 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 May 2020 13:41:57 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04GBfqGe005999; Sat, 16 May 2020 13:41:52 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04GBfR4Q059020; Sat, 16 May 2020 13:41:37 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005161141.04GBfR4Q059020@fire.js.berklix.net> To: Mark Linimon cc: "freebsd-arch@freebsd.org" , Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Fri, 15 May 2020 23:20:36 -0000." <20200515232035.GC516@lonesome.com> Date: Sat, 16 May 2020 13:41:27 +0200 X-Rspamd-Queue-Id: 49PNfd2bxyz4QjM X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.13 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.84)[-0.839,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.07)[0.072,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RECEIVED_SPAMHAUS_PBL(0.00)[228.201.82.46.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 11:42:02 -0000 Mark Linimon wrote: > On Sat, May 16, 2020 at 01:06:18AM +0200, Julian H. Stacey wrote: > > > From: John Baldwin > > > I've watched many threads involving you over the past several years, > > > > Flame bait declined. > > I am going to side with jhb here. Your commonly-relied-upon tactic Flame bait declined. > I offer this *regardless* of whether I agree with what you said, or not. Ignoring thread topic abuses list. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-arch@freebsd.org Sat May 16 14:37:59 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 776662F413D for ; Sat, 16 May 2020 14:37:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from 44-233-67-66-mail.ore.mailhop.org (44-233-67-66-mail.ore.mailhop.org [44.233.67.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49PSYf6bt7z4ZWY for ; Sat, 16 May 2020 14:37:58 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1589639871; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=uO36zKgTd4FUHqBi30f/+kbdHRkxNxv2EwVDcqgvdUvs82I3RCSRJ2pBcJ7vAAL3/gL9GxIxT+V6Q LyR/hgPRwT24bT6ytucNPKAZq/5JeX2T8N8NItOI4AiOFzmvlGUclafawygxuGeY9kct1dR9LfJaRX JovSoUAuvGjrFn2Wew7TRQztGJp27oWNNnTnP0d9CYl1sAmtXqTAbVprU6dgyJ+4aEUs8LWIGCD+IR RO3rI+ZuPAY3RROxZzseKEBBervn4cIi2csYX4+7i3MRBMa2nYDYJmBB/MuL1zY+BsFYHnP3Q+gO9e QWVd3rcp8fi18W9Cs6XQwlMGhlFUe2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=weMMHs7NHMAXEF8QP+LzlL1XQZGO0Pp2EcGlw16UfJY=; b=exnceyHLWufB4BRr2HMJ2bBKaualFem0Py3YPzHhpR5f1LH17vhVipAW/Jz5DtRqmJrK2u9+WhRBg RhgQX59Rx+xM6A6wEBdNg2WPEE4IL4elRW9thPoBkiFpV9wxkcZO9Iyy87LNtC/shpcJ0zkkecpNLu PPl6yG1uk2h0HKYY45+XiXWYQOlxQucvb//78w0yTkRhXkXKvcqKV7ojU6j7HejBfx5nhOFseuiqGW 9+J++6le0BXR5jvr/R1W/a/bYSM1UC0pSwhPtI2unM/0TvouCj3rD2O/tg1vO2/Rjzba1CwsLwbUcy BjgtgioQJNeVCu5Enorlw6yuyYRlb8g== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=weMMHs7NHMAXEF8QP+LzlL1XQZGO0Pp2EcGlw16UfJY=; b=gOYxdcX6JGkXmyZjH99pcqRlhq6khQ36A3z3U92cn3JYP3kTr9exfsuRy+1tWB+aCZNhhpatG8qBI prYkGnACBf78vSw0U+W7agLgYoUIfB0ee096rYL7wumXuBcMRU2NiPKXqFGOUCHtcHO7eDZCI/Pm01 vy5l+btj77ESAZh9/EQGv/52O0PDLk+tf4o8V5eI522FBicWVFsezMJnsX41Ah9MbtfO351eBSkHHQ awxH6FqBOCSfuzFI3n/FcgTnfhHEilrwpU21aLIPFQWXpbO4Ifn6PiRtrRj+fE0tYhnRHBFGgwPwpc ZtVOwDmZuPOKkyhbrKz6PbYj9TD2xuA== X-MHO-RoutePath: aGlwcGll X-MHO-User: cf142815-9782-11ea-b10c-b5956a7dd1a1 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id cf142815-9782-11ea-b10c-b5956a7dd1a1; Sat, 16 May 2020 14:37:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 04GEbj2O094684; Sat, 16 May 2020 08:37:46 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <8c06a51433b7bcca1e28154db9b65cee00fbc2a4.camel@freebsd.org> Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: Ian Lepore To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" Date: Sat, 16 May 2020 08:37:45 -0600 In-Reply-To: <202005161141.04GBfR4Q059020@fire.js.berklix.net> References: <202005161141.04GBfR4Q059020@fire.js.berklix.net> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49PSYf6bt7z4ZWY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.81 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.81)[-0.813,0]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 14:37:59 -0000 On Sat, 2020-05-16 at 13:41 +0200, Julian H. Stacey wrote: > Mark Linimon wrote: > > On Sat, May 16, 2020 at 01:06:18AM +0200, Julian H. Stacey wrote: > > > > From: John Baldwin > > > > I've watched many threads involving you over the past several > > > > years, > > > > > > Flame bait declined. > > > > I am going to side with jhb here. Your commonly-relied-upon tactic > > Flame bait declined. > > > I offer this *regardless* of whether I agree with what you said, or > > not. > > Ignoring thread topic abuses list. > The only "abuse" is what pours out of you every time you post to these lists. You've never contributed anything in all the years I've been reading these lists. You just attack people for their volunteer work in the most hyperbolic terms possible, accusing them of having bad motives, and always because of simply having a different opinion than yours about what should be done. You never offer technical reasons for any of your objections, you just complain that you disagree with some action and berate the people who don't agree with you. -- Ian From owner-freebsd-arch@freebsd.org Sat May 16 15:18:29 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 35F522F4CEC; Sat, 16 May 2020 15:18:29 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PTSN26wTz4c9Q; Sat, 16 May 2020 15:18:27 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C9E4.dip0.t-ipconnect.de [46.82.201.228]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04GFIKf2080724 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 May 2020 17:18:24 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04GFIK98007397; Sat, 16 May 2020 17:18:20 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04GFIA0a099390; Sat, 16 May 2020 17:18:20 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005161518.04GFIA0a099390@fire.js.berklix.net> To: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Fri, 15 May 2020 20:30:08 -0700." <2ea8236f935a4c786a0f4f06ca1d3ea3@udns.ultimatedns.net> Date: Sat, 16 May 2020 17:18:10 +0200 X-Rspamd-Queue-Id: 49PTSN26wTz4c9Q X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-0.12 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.815,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.20)[-0.200,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[228.201.82.46.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 15:18:29 -0000 Another use of "cat ." is to see names of transient files a tool creates, & normaly deletes, if not aborting, so one can find same name junk elsewhere, & search for tool causing junk, & ensure other data files avoid using names that would be zapped. While blocking "cat ." might be worked round if not in a jail, & or if using fsdb & sysctl etc, it would add to a more BSD specific environment, where standard portable Unix skills was insufficient, & more time needed to search & learn BSD extras. Every obstacle costs employers time = money. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-arch@freebsd.org Sat May 16 15:21:40 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2A7A62F4EF1 for ; Sat, 16 May 2020 15:21:40 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PTX33Mp5z4cZ3; Sat, 16 May 2020 15:21:39 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C9E4.dip0.t-ipconnect.de [46.82.201.228]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04GFLX6h080766 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 May 2020 17:21:37 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04GFLXie007418; Sat, 16 May 2020 17:21:33 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04GFLNSV099460; Sat, 16 May 2020 17:21:33 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005161521.04GFLNSV099460@fire.js.berklix.net> To: Ian Lepore cc: "freebsd-arch@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Sat, 16 May 2020 08:37:45 -0600." <8c06a51433b7bcca1e28154db9b65cee00fbc2a4.camel@freebsd.org> Date: Sat, 16 May 2020 17:21:23 +0200 X-Rspamd-Queue-Id: 49PTX33Mp5z4cZ3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-0.25 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.31)[-0.306,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_MEDIUM(-0.85)[-0.848,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[228.201.82.46.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 15:21:40 -0000 Ian Lepore wrote: > The only "abuse" is what pours out of you every time you post to these > Flame bait declined. Ignoring thread topic abuses list. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-arch@freebsd.org Sat May 16 16:26:23 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5940F2F66F5; Sat, 16 May 2020 16:26:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PVyl1dx2z3CrH; Sat, 16 May 2020 16:26:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 2680C76B6; Sat, 16 May 2020 16:26:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f52.google.com with SMTP id g20so2644450qvb.9; Sat, 16 May 2020 09:26:23 -0700 (PDT) X-Gm-Message-State: AOAM531HrVnIwsiDY/xlC3WQk/DcdgGy2okwf7HpGJHuHkKl9kq9f2cV 4pl1B6r9aTFpWPoB9W+RgFuMhtDkCh96N/6opX4= X-Google-Smtp-Source: ABdhPJwr5nlj8YBBNBIITL7PfBdsTPYlMQnUCoVbA9fmFgt2VNocPcw4h8exB28ETDru9uJPaYj9/S6xUxjfZoTr1GA= X-Received: by 2002:a0c:f054:: with SMTP id b20mr8334283qvl.112.1589646382677; Sat, 16 May 2020 09:26:22 -0700 (PDT) MIME-Version: 1.0 References: <2ea8236f935a4c786a0f4f06ca1d3ea3@udns.ultimatedns.net> <202005161518.04GFIA0a099390@fire.js.berklix.net> In-Reply-To: <202005161518.04GFIA0a099390@fire.js.berklix.net> From: Kyle Evans Date: Sat, 16 May 2020 11:26:11 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 16:26:23 -0000 On Sat, May 16, 2020 at 10:18 AM Julian H. Stacey wrote: > > Another use of "cat ." is to see names of transient files a tool > creates, & normaly deletes, if not aborting, so one can find same > name junk elsewhere, & search for tool causing junk, > & ensure other data files avoid using names that would be zapped. > > While blocking "cat ." might be worked round if not in a jail, & > or if using fsdb & sysctl etc, it would add to a more BSD specific > environment, where standard portable Unix skills was insufficient, > & more time needed to search & learn BSD extras. Every obstacle > costs employers time = money. > This scenario is just a bit too generic for me to be able to relate to, because I've never been in a situation where I would've had to or just randomly used `cat .` to discover junk files. This also isn't really a transferable skill to other modern OS and filesystems, as oftentimes they won't or can't give you anything useful with read(2). That said, I've written a MAC policy that can live atop the current patch to lift all of the restrictions except the sysctl needing to be set: https://people.freebsd.org/~kevans/mac-read_dir.diff -> I could even be convinced fairly easily to commit it, if you'd find that acceptable. The policy ends up looking generically useful, as you can lift just the jail root restriction or you can allow any user to cat a directory. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Sat May 16 17:52:41 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 08F202F83B8 for ; Sat, 16 May 2020 17:52:41 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PXtJ6SFnz3JTm for ; Sat, 16 May 2020 17:52:40 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id D030C81AE for ; Sat, 16 May 2020 17:52:40 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f174.google.com with SMTP id z80so6049375qka.0 for ; Sat, 16 May 2020 10:52:40 -0700 (PDT) X-Gm-Message-State: AOAM530TOrKMQcJQoa+xA1dWlIL/YUQBRgXRC9EVcWWNptpuY3xvAMIR rhaKhF/sZc+X5fRYtMZzSBb6oqClphW5vw1Lfao= X-Received: by 2002:a37:8c4:: with SMTP id 187mt9369871qki.34.1589651560186; Sat, 16 May 2020 10:52:40 -0700 (PDT) MIME-Version: 1.0 References: <2ea8236f935a4c786a0f4f06ca1d3ea3@udns.ultimatedns.net> <202005161518.04GFIA0a099390@fire.js.berklix.net> In-Reply-To: From: Kyle Evans Date: Sat, 16 May 2020 12:52:29 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd Cc: "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 17:52:41 -0000 On Sat, May 16, 2020 at 11:26 AM Kyle Evans wrote: > > On Sat, May 16, 2020 at 10:18 AM Julian H. Stacey wrote: > > > > Another use of "cat ." is to see names of transient files a tool > > creates, & normaly deletes, if not aborting, so one can find same > > name junk elsewhere, & search for tool causing junk, > > & ensure other data files avoid using names that would be zapped. > > > > While blocking "cat ." might be worked round if not in a jail, & > > or if using fsdb & sysctl etc, it would add to a more BSD specific > > environment, where standard portable Unix skills was insufficient, > > & more time needed to search & learn BSD extras. Every obstacle > > costs employers time = money. > > > > This scenario is just a bit too generic for me to be able to relate > to, because I've never been in a situation where I would've had to or > just randomly used `cat .` to discover junk files. This also isn't > really a transferable skill to other modern OS and filesystems, as > oftentimes they won't or can't give you anything useful with read(2). > > That said, I've written a MAC policy that can live atop the current > patch to lift all of the restrictions except the sysctl needing to be > set: https://people.freebsd.org/~kevans/mac-read_dir.diff -> I could > even be convinced fairly easily to commit it, if you'd find that > acceptable. The policy ends up looking generically useful, as you can > lift just the jail root restriction or you can allow any user to cat a > directory. > I've finished up a manpage for this MAC module and the rest of the build infrastructure, publishing it for review here: https://reviews.freebsd.org/D24862 -> the formal dependency on the previous review has been documented. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Sat May 16 17:58:57 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AE0572F86FD; Sat, 16 May 2020 17:58:57 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PY1X1fGvz3Jrt; Sat, 16 May 2020 17:58:55 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C9E4.dip0.t-ipconnect.de [46.82.201.228]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04GHwm6B081960 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 May 2020 19:58:52 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04GHwldH008345; Sat, 16 May 2020 19:58:48 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04GHwbpZ038671; Sat, 16 May 2020 19:58:47 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005161758.04GHwbpZ038671@fire.js.berklix.net> To: Kyle Evans cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Sat, 16 May 2020 11:26:11 -0500." Date: Sat, 16 May 2020 19:58:37 +0200 X-Rspamd-Queue-Id: 49PY1X1fGvz3Jrt X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.21 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; NEURAL_SPAM_LONG(0.11)[0.107,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_MEDIUM(-0.80)[-0.797,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[228.201.82.46.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 17:58:57 -0000 Kyle Evans wrote: > On Sat, May 16, 2020 at 10:18 AM Julian H. Stacey wrote: > > > > Another use of "cat ." is to see names of transient files a tool > > creates, & normaly deletes, if not aborting, so one can find same > > name junk elsewhere, & search for tool causing junk, > > & ensure other data files avoid using names that would be zapped. > > > > While blocking "cat ." might be worked round if not in a jail, & > > or if using fsdb & sysctl etc, it would add to a more BSD specific > > environment, where standard portable Unix skills was insufficient, > > & more time needed to search & learn BSD extras. Every obstacle > > costs employers time = money. > > > > This scenario is just a bit too generic for me to be able to relate > to, because I've never been in a situation where I would've had to or > just randomly used `cat .` to discover junk files. Yes, it's a rare usage, I dont do it often. > This also isn't > really a transferable skill to other modern OS and filesystems, as > oftentimes they won't or can't give you anything useful with read(2). > > That said, I've written a MAC policy that can live atop the current > patch to lift all of the restrictions except the sysctl needing to be > set: https://people.freebsd.org/~kevans/mac-read_dir.diff -> I could > even be convinced fairly easily to commit it, if you'd find that > acceptable. The policy ends up looking generically useful, as you can > lift just the jail root restriction or you can allow any user to cat a > directory. > > Thanks, > > Kyle Evans Thanks, It's good if its all sysctl without reboot, (taking (phk's I recall) point about an fs not surviving a reboot) It sounds useful, if it allows 3 or is that more ? way choice between eg {old v. new} x { root v. non root } x { inside a jail v. outside } = 8 ? If all of that, I guess we'd just be down to a relaxed consideration about what default mode was for now & later. If there was change there, we'd need to check what policy is about giving advance notice of changes in RELNOTES. If RELNOTES required long notice than wanted , that could be worked round easily by implementing code, & merely issuing notice that defaults would change to new policy later at releasese x.y. I took a quick glance at https://people.freebsd.org/~kevans/mac-read_dir.diff but I'm sorry loads of real life distraction here. I'm sure others will want to read it. Thanks for working hard to cater for all cases ! :-) Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-arch@freebsd.org Sat May 16 18:28:43 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AECE22F9802; Sat, 16 May 2020 18:28:43 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PYgv43vsz3M3p; Sat, 16 May 2020 18:28:43 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 79CD1854C; Sat, 16 May 2020 18:28:43 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f177.google.com with SMTP id f189so6071628qkd.5; Sat, 16 May 2020 11:28:43 -0700 (PDT) X-Gm-Message-State: AOAM531yf1gg7rAAsFyLhSnwvDajYezNNRBrpSl5cyayLvCxJG4jUQaU HD2Ec2iMi9F4pcpwR9bBtFaF3ef02+YmKFw3mMw= X-Google-Smtp-Source: ABdhPJxc/j7l84amDzf+f7rNCbxmr/AYNYxnQxP1kqm9nbioUJyIAvwtfCuTLmEVKmdiNCzcmU7jypra2xQm8m92RgY= X-Received: by 2002:a37:2711:: with SMTP id n17mr9071974qkn.430.1589653723013; Sat, 16 May 2020 11:28:43 -0700 (PDT) MIME-Version: 1.0 References: <202005161758.04GHwbpZ038671@fire.js.berklix.net> In-Reply-To: <202005161758.04GHwbpZ038671@fire.js.berklix.net> From: Kyle Evans Date: Sat, 16 May 2020 13:28:32 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 18:28:43 -0000 On Sat, May 16, 2020 at 12:59 PM Julian H. Stacey wrote: > > Kyle Evans wrote: > > [... snip ...] > > That said, I've written a MAC policy that can live atop the current > > patch to lift all of the restrictions except the sysctl needing to be > > set: https://people.freebsd.org/~kevans/mac-read_dir.diff -> I could > > even be convinced fairly easily to commit it, if you'd find that > > acceptable. The policy ends up looking generically useful, as you can > > lift just the jail root restriction or you can allow any user to cat a > > directory. > > > > Thanks, > > > > Kyle Evans > > Thanks, > It's good if its all sysctl without reboot, (taking (phk's I recall) point > about an fs not surviving a reboot) > Yup- assuming you're not in the perhaps rare situation where you both need this *and* you can't get the kmod loaded, it's all sysctl-based. > It sounds useful, if it allows 3 or is that more ? way choice between eg > {old v. new} x { root v. non root } x { inside a jail v. outside } = 8 ? > It's not quite that flexible because this is harder to capture, it allows three different possibilities: - New behavior - Old behavior - Middle ground, where unprivileged users can't `cat .` but jail root can #3 was thrown in because I suspect someone somewhere may not necessarily care for preservation of any old users' capability to do this, but for those systems where the previously cited 'jail root is root' is true (since I think we agree that that can be the case, but often isn't). > If all of that, I guess we'd just be down to a relaxed consideration about > what default mode was for now & later. > > If there was change there, we'd need to check what policy is about giving > advance notice of changes in RELNOTES. > > If RELNOTES required long notice than wanted , that could be worked round > easily by implementing code, & merely issuing notice that defaults would > change to new policy later at releasese x.y. > Here's how this breaks down; these steps haven't been included in the review thus far because I often just assume that it's clear this will happen: - UPDATING: Users of 13.0-CURRENT will receive notice via UPDATING that this is changing, along with mention of the MAC policy to return to the legacy behavior. Some bumps of this nature are to be expected amongst -CURRENT, and this is how we communicate them to those following along at home. - RELNOTES: This will definitely be included in the 13.0 relnotes. I'm tentatively planning to MFC some of the functionality (security.bsd.allow_read_dir but with a default of 1 to preserve branch behavior) to allow users of stable/12 to turn it off and get the 13.0 behavior earlier if they want or see if it breaks any of their stuff, which I will try and use as a vector to get the future default change into the 12.2 release notes as well so that there's plenty of advance notice. I suspect re@ will happily include it, given the history. > I took a quick glance at > https://people.freebsd.org/~kevans/mac-read_dir.diff but I'm sorry > loads of real life distraction h These kinds of bumps are to be expectedere. I'm sure others will want t > read it. Thanks for working hard to cater for all cases ! :-) > This is fine. =-) Honestly, I have really been trying my best to optimize the outcome for all of our users. I do fully believe at this point in the discussion that the majority of our userbase is best served by changing the default behavior here, and I want to be able to do so without burning community relations. My suspicion is that those of you that do make use of this, do so infrequently and would happily or maybe even usually run a system with: root@viper:~# cat /boot/loader.conf # Of course, this could instead be baked into your kernel config mac_read_dir_load="YES" root@viper:~# cat /etc/sysctl.conf security.mac.read_dir.jail_root=1 # The following perhaps even turned off or commented out to serve just as a reminder, until you actually need it security.bsd.allow_read_dir=1 My working assumption being that you don't often do this as any old unprivileged user, but might be doing so as jail root. Of course, `security.mac.read_dir.jail_root=1` might instead be `security.mac.read_dir.all_users=1` to fully follow the existing behavior. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Sat May 16 21:42:57 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 34EB22FE426; Sat, 16 May 2020 21:42:57 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Pf005vLbz44GF; Sat, 16 May 2020 21:42:56 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 04GLhB29073174 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 16 May 2020 14:43:18 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "Julian H. Stacey" In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Kyle Evans Subject: Re: [HEADSUP] Disallowing read() of a directory fd Date: Sat, 16 May 2020 14:43:17 -0700 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49Pf005vLbz44GF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.51 / 15.00]; NEURAL_HAM_MEDIUM(-0.56)[-0.557,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; NEURAL_HAM_LONG(-0.96)[-0.956,0] X-Mailman-Approved-At: Sat, 16 May 2020 21:51:43 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 21:42:57 -0000 On Sat, 16 May 2020 13:28:32 -0500 Kyle Evans kevans@freebsd=2Eorg said > On Sat, May 16, 2020 at 12:59 PM Julian H=2E Stacey wrote= : > > > > Kyle Evans wrote: > > > [=2E=2E=2E snip =2E=2E=2E] > > > That said, I've written a MAC policy that can live atop the current > > > patch to lift all of the restrictions except the sysctl needing to be > > > set: https://people=2Efreebsd=2Eorg/~kevans/mac-read_dir=2Ediff -> I could > > > even be convinced fairly easily to commit it, if you'd find that > > > acceptable=2E The policy ends up looking generically useful, as you can > > > lift just the jail root restriction or you can allow any user to cat = a > > > directory=2E > > > > > > Thanks, > > > > > > Kyle Evans > > > > Thanks, > > It's good if its all sysctl without reboot, (taking (phk's I recall) po= int > > about an fs not surviving a reboot) > > >=20 > Yup- assuming you're not in the perhaps rare situation where you both > need this *and* you can't get the kmod loaded, it's all sysctl-based=2E >=20 > > It sounds useful, if it allows 3 or is that more ? way choice between e= g > > {old v=2E new} x { root v=2E non root } x { inside a jail v=2E outside } =3D = 8 ? > > >=20 > It's not quite that flexible because this is harder to capture, it > allows three different possibilities: >=20 > - New behavior > - Old behavior > - Middle ground, where unprivileged users can't `cat =2E` but jail root can >=20 > #3 was thrown in because I suspect someone somewhere may not > necessarily care for preservation of any old users' capability to do > this, but for those systems where the previously cited 'jail root is > root' is true (since I think we agree that that can be the case, but > often isn't)=2E >=20 > > If all of that, I guess we'd just be down to a relaxed consideration ab= out > > what default mode was for now & later=2E > > > > If there was change there, we'd need to check what policy is about givi= ng > > advance notice of changes in RELNOTES=2E > > > > If RELNOTES required long notice than wanted , that could be worked rou= nd > > easily by implementing code, & merely issuing notice that defaults woul= d > > change to new policy later at releasese x=2Ey=2E > > >=20 > Here's how this breaks down; these steps haven't been included in the > review thus far because I often just assume that it's clear this will > happen: >=20 > - UPDATING: Users of 13=2E0-CURRENT will receive notice via UPDATING > that this is changing, along with mention of the MAC policy to return > to the legacy behavior=2E Some bumps of this nature are to be expected > amongst -CURRENT, and this is how we communicate them to those > following along at home=2E >=20 > - RELNOTES: This will definitely be included in the 13=2E0 relnotes=2E I'm > tentatively planning to MFC some of the functionality > (security=2Ebsd=2Eallow_read_dir but with a default of 1 to preserve > branch behavior) to allow users of stable/12 to turn it off and get > the 13=2E0 behavior earlier if they want or see if it breaks any of > their stuff, which I will try and use as a vector to get the future > default change into the 12=2E2 release notes as well so that there's > plenty of advance notice=2E I suspect re@ will happily include it, given > the history=2E >=20 > > I took a quick glance at > > https://people=2Efreebsd=2Eorg/~kevans/mac-read_dir=2Ediff but I'm sorry > > loads of real life distraction h These kinds of bumps are to be expecte= dere=2E > > I'm sure others will want t > > read it=2E Thanks for working hard to cater for all cases ! :-) > > >=20 > This is fine=2E =3D-) Honestly, I have really been trying my best to > optimize the outcome for all of our users=2E I do fully believe at this > point in the discussion that the majority of our userbase is best > served by changing the default behavior here, and I want to be able to > do so without burning community relations=2E >=20 > My suspicion is that those of you that do make use of this, do so > infrequently and would happily or maybe even usually run a system > with: >=20 > root@viper:~# cat /boot/loader=2Econf > # Of course, this could instead be baked into your kernel config > mac_read_dir_load=3D"YES" >=20 > root@viper:~# cat /etc/sysctl=2Econf > security=2Emac=2Eread_dir=2Ejail_root=3D1 > # The following perhaps even turned off or commented out to serve just > as a reminder, until you actually need it > security=2Ebsd=2Eallow_read_dir=3D1 >=20 > My working assumption being that you don't often do this as any old > unprivileged user, but might be doing so as jail root=2E Of course, > `security=2Emac=2Eread_dir=2Ejail_root=3D1` might instead be > `security=2Emac=2Eread_dir=2Eall_users=3D1` to fully follow the existing > behavior=2E >=20 > Thanks, No=2E Thank *you*, Kyle=2E :-) I just want to take this opportunity to thank you for all the work you put into this -- both the semi-anticipated code, and perhaps more significantly, the _social_ work that went into getting this concept into a usable/functional state=2E While I have only glossed over your diff, and therefore can't (yet) reasonably evaluate it=2E Do you anticipate any impact/changes to overall performance? In closing; some of here have been hacking on this code since before Net/1, and are fairly sensitive about some new-comer messing with our UNIX heritage=2E I look back fondly remembering waiting for tubes to warm up, and threading/spooling up tapes=2E I don't remember being too fond of having to wait for someone elses job to finish, so I could use the damn thing=2E ;-) Thanks again! --Chris >=20 > Kyle Evans > _______________________________________________ > freebsd-hackers@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd=2Eorg= "