From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id BCBE9396E866 for ; Fri, 9 Apr 2021 04:34:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BCBE9396E866 Received: by mail-pg1-x533.google.com with SMTP id q10so2950594pgj.2 for ; Thu, 08 Apr 2021 21:34: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; bh=GlsjPDo7RkocLChxK7Fxzcfsf17laZ+BFZ3vGjEhgAM=; b=sR377NI6B484P9c2sKxajlWKhda0HbFANlUFpgiJTddnJGkBQ0gYXPOH2PLnvgtSOS MDx0T4pKknsVheNmjbV7jhvwt0RJDEQO1Savy2nxogaKin7R35XwNVFcwyKn2yoTwOxT kqSFPEvGLAgDNqpcIQG78FcNeC6Y+SMHvoiWsllhOGX/puDefpXEmUQODGvcTa/GYSYA i7YHmpHoMKYP9n1thQWQhmQ2b7EzVfkR2OFtBNtpsUGWmpHk6KmewQyrTWRRqVUKs6hH 6XnJ7Hs5sprZ8C9mSKyJeNXtQ+nULf3YFdDfsUn9Q3WJ/awfWCyAcZDxXsLxvE0aJ1MO 1HTA== X-Gm-Message-State: AOAM533RSUmLcpzza82pr6LNxqV3ISIB9jw11MyuIztCWDXxULhO0I2S 0kqGffAm3mg5hSpxnGuFaVELTU7hLdpmsrT+WYBG6U5eC7o6dg== X-Google-Smtp-Source: ABdhPJyGCreh8wpyPEoJVWR6fmENA5kQRtDtkeF839AtTk/nN9sIwqsbaUaE0xl7Dde1qBVnAitmNLLqF0yo6XbTsNU= X-Received: by 2002:a63:570b:: with SMTP id l11mr11270580pgb.193.1617942897411; Thu, 08 Apr 2021 21:34:57 -0700 (PDT) MIME-Version: 1.0 References: <1462778363.20210409044512@yandex.ru> In-Reply-To: <1462778363.20210409044512@yandex.ru> From: Orgad Shaneh Date: Fri, 9 Apr 2021 07:34:46 +0300 Message-ID: Subject: Re: A problem with noacl+umask+chmod result To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 04:35:02 -0000 On Fri, Apr 9, 2021 at 4:50 AM Andrey Repin wrote: > > Greetings, Orgad Shaneh! > > > On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh wrote: > >> > >> Hi, > >> > >> If a filesystem is mounted with noacl, calling chmod to add write > >> permissions after umasking this permission doesn't work. Demonstrated > >> with command-line and C++. > >> > >> Did I miss something or is this a real bug? According to umask man, it > >> should only affect newly created files and directories, but I didn't > >> find anything that relates to chmod. > >> > >> Command-line: > >> touch foo > >> ls -l foo > >> # -rw-r--r-- ... foo > >> umask 200 > >> chmod 0 foo > >> ls -l foo > >> # -r--r--r-- ... foo > >> chmod 200 foo > >> ls -l foo > >> # -r--r--r-- ... foo > >> # Expected to have rw > > > Marco Atzeri replied to the mailing list but did not CC me, so I > > didn't receive it: > > The expectation is that you subscribe to the list of interest. Why? If I report a bug, I'm interested in this bug, and I don't want to receive dozens of emails every day about other issues. Every time you report a bug to a project on github/jira/whatever, you subscribe to everything in this project? > >> without ACL you can not expect the POSIX scheme to properly work. > >> see > >> https://cygwin.com/cygwin-ug-net/ntsec.html > >> to understand how Cygwin uses ACL to mimic POSIX permissions > > > Thanks Marco! > > > I'm well aware of that. I don't expect it to work properly. From what > > I know, it can only set/unset user write bit. Read bits are always > > enabled, even on chmod 0. > > > What I do expect is that the write bit will not be affected by umask. > > umask should only affect newly created files, not direct chmod > > commands. > > Yet again: using chmod on noacl filesystem is likely to cause more harm than > good. You may very well end up with an unusable filesystem until you fix > permissions by hands. With noacl, chmod is capable of setting and unsetting the user write bit, and I expect it to do that. I actually found this issue because CMake unit tests failed for me on MSYS which sets noacl. Anyway, I found the curprit. The problem is not with chmod, but with stat. fhandler_base::fstat_helper has this line: /* This fakes the permissions of all files to match the current umask. */ buf->st_mode &= ~(cygheap->umask); So chmod does set the write bit correctly, but stat doesn't report it. I can see why this is needed, so I'll adapt the CMake tests to workaround this. Thank you! - Orgad