From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30E66C43461 for ; Thu, 10 Sep 2020 16:43:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E4F36214F1 for ; Thu, 10 Sep 2020 16:43:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727070AbgIJQnm (ORCPT ); Thu, 10 Sep 2020 12:43:42 -0400 Received: from brightrain.aerifal.cx ([216.12.86.13]:52470 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727066AbgIJQjw (ORCPT ); Thu, 10 Sep 2020 12:39:52 -0400 Date: Thu, 10 Sep 2020 12:39:50 -0400 From: Rich Felker To: Christoph Hellwig Cc: linux-api@vger.kernel.org, Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] vfs: add fchmodat2 syscall Message-ID: <20200910163949.GJ3265@brightrain.aerifal.cx> References: <20200910142335.GG3265@brightrain.aerifal.cx> <20200910162059.GA18228@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200910162059.GA18228@infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 10, 2020 at 05:20:59PM +0100, Christoph Hellwig wrote: > On Thu, Sep 10, 2020 at 10:23:37AM -0400, Rich Felker wrote: > > userspace emulation done in libc implementations. No change is made to > > the underlying chmod_common(), so it's still possible to attempt > > changes via procfs, if desired. > > And that is the goddamn problem. We need to fix that _first_. Can you clarify exactly what that is? Do you mean fixing the underlying fs backends, or just ensuring that the chmod for symlinks doesn't reach them by putting the check in chmod_common? I'm ok with any of these. > After that we can add sugarcoating using new syscalls if needed. The new syscall is _not_ about this problem. It's about the missing flags argument and inability to implement fchmodat() without access to procfs. The above problem is just something you encounter and have to make a decision about in order to fix the missing flags problem and make a working AT_SYMLINK_NOFOLLOW. Rich