Received: (at submit) by debbugs.gnu.org; 6 May 2022 11:53:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 06 07:53:37 2022 Received: from localhost ([127.0.0.1]:47315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nmwWf-0004KH-0j for submit <at> debbugs.gnu.org; Fri, 06 May 2022 07:53:37 -0400 Received: from lists.gnu.org ([209.51.188.17]:33718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raphael.melotte@HIDDEN>) id 1nmwWc-0004KA-Tv for submit <at> debbugs.gnu.org; Fri, 06 May 2022 07:53:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37370) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <raphael.melotte@HIDDEN>) id 1nmwWc-0007rB-Ax for bug-guix@HIDDEN; Fri, 06 May 2022 07:53:34 -0400 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]:33641) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <raphael.melotte@HIDDEN>) id 1nmwWa-0000v3-4w for bug-guix@HIDDEN; Fri, 06 May 2022 07:53:33 -0400 Received: by mail-ed1-x52b.google.com with SMTP id p4so8441204edx.0 for <bug-guix@HIDDEN>; Fri, 06 May 2022 04:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mind.be; s=google; h=message-id:date:mime-version:user-agent:content-language:from :subject:to:content-transfer-encoding; bh=l339khYn/JMYwLpPIRmO0/c/eREFupqmqLCtv1D4EM4=; b=QmHmOA+SmmP7H0GJxpSWsUUuuHKghHGIwJFRezKYWPkx8iuz5FyvVRrMqeYHH9E9hs ZwvZLQzKtODOsQt1jVFbuMPej2DV3zKjl+btlQjQvA0qhQ4/X4IUboAELofreHdnSSLv ait/kCe+C68hd5P7gGrszhzpMsappB3YkMoJFj5sZep8dhPERjVjQd2ySBC5HnxWXu+Z wmS0WIilYvuaTBz76L3n0rjS7Bj340LZeCfN3DMpu9DIdtHyHLjdZxEwSsVu7+WTaYMN baXhuRAZctfsIhcxm7F8nqvI1zZ/Og3v1uEu58qF1ojNiLTAStyJPlJjuzi6HLc4nHE0 ubEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:from:subject:to:content-transfer-encoding; bh=l339khYn/JMYwLpPIRmO0/c/eREFupqmqLCtv1D4EM4=; b=PYDaea2271YOVQZJxHvsa93Hr4yGzTFHBJhFZ8tFkSIlbG7OpwMG1qyMSRjxuBKGG2 CiNB6HULtwDSVpIH502Jnkg1L1640Y0H2ZhbU4I3KTjyBEq/88lduNttplirvudNUO+U ewEiQZ5wLCaMbT+Hh2gPZ4qpYm99dPbKRdpyrxHyDrDGTSL8sq3ONe/wDmjzIYHBvHrU wtc/CyiEaQQQVdIYj/oo+DP/OxtV89cwE8VtUNIY2lTtWsDj92dCbNcvxQ8JR6UaXysC 0zxasfCokOcdz9aH9ZDIhFD+Yrvp0RVxRLoY1l9yWpzX4nWCNJzLYRmPwEcj8x6Uk2Uc dDOQ== X-Gm-Message-State: AOAM5324PQUgHmoesyZXJFBbuJtXW6cF2HJe3FIMoilYJwFzusCXLOKN aDRXMYzRgszN/ioYpgFzreqARUm5BuvvYfQn X-Google-Smtp-Source: ABdhPJwr7DRdMEZydGP8c2MAeDFBbZgldNfahGyp7Yc1yGXcTYZiva2frEQNvnqsm+PwS9uCGs2zOw== X-Received: by 2002:a05:6402:747:b0:428:1f98:d17 with SMTP id p7-20020a056402074700b004281f980d17mr3075691edy.57.1651838009607; Fri, 06 May 2022 04:53:29 -0700 (PDT) Received: from ?IPV6:2a02:a03f:6bfb:d00:4149:7987:6bcf:f1e1? ([2a02:a03f:6bfb:d00:4149:7987:6bcf:f1e1]) by smtp.gmail.com with ESMTPSA id my50-20020a1709065a7200b006f3ef214e79sm1846550ejc.223.2022.05.06.04.53.28 for <bug-guix@HIDDEN> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 May 2022 04:53:29 -0700 (PDT) Message-ID: <65255136-db7c-7c63-ece4-b4182c861ba1@HIDDEN> Date: Fri, 6 May 2022 13:53:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.8.0 Content-Language: en-US From: =?UTF-8?B?UmFwaGHDq2wgTcOpbG90dGU=?= <raphael.melotte@HIDDEN> Subject: make-file-writable adds the executable bit on some files added to the store To: bug-guix@HIDDEN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::52b; envelope-from=raphael.melotte@HIDDEN; helo=mail-ed1-x52b.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) Hello, Recently I tried to use Lynis provided by Guix again. I was pretty sure it worked some time ago, but the current version refuses to start: ====== Fatal error: permissions of file /gnu/store/52yj60gjhzkrg10dq2xybfwx7g5x9z9w-lynis-3.0.6/share/lynis/db/languages/en are not strict enough. Access to 'owner' should be read-write, or read. Change with: chmod u=rw /gnu/store/52yj60gjhzkrg10dq2xybfwx7g5x9z9w-lynis-3.0.6/share/lynis/db/languages/en ====== The permissions on files in the "languages" folder in the store are surprising (I omitted some for clarity) : ====== ... -r--r--r-- 2 root root 4033 Jan 1 1970 da -r-xr-xr-x 2 root root 4187 Jan 1 1970 de lrwxrwxrwx 1 root root 2 Jan 1 1970 de-AT -> de -r-xr-xr-x 2 root root 3865 Jan 1 1970 en lrwxrwxrwx 1 root root 2 Jan 1 1970 en-GB -> en lrwxrwxrwx 1 root root 2 Jan 1 1970 en-US -> en -r--r--r-- 2 root root 4258 Jan 1 1970 es -r--r--r-- 2 root root 4076 Jan 1 1970 fi -r--r--r-- 2 root root 4210 Jan 1 1970 fr ... ====== Note for example that "da" is "0444", but "de" and "en" are "0555" (which is why Lynis refuses to start). I wanted to know why this is the case, so I built Lynis from source using Guix. Strangely, in the checkout the permissions look fine (no executable bit): ====== -r--r--r-- 1 root root 4033 jan 1 1970 da -r--r--r-- 1 root root 4187 jan 1 1970 de lrwxrwxrwx 1 root root 2 jan 1 1970 de-AT -> de -r--r--r-- 1 root root 3865 jan 1 1970 en lrwxrwxrwx 1 root root 2 jan 1 1970 en-GB -> en lrwxrwxrwx 1 root root 2 jan 1 1970 en-US -> en -r--r--r-- 1 root root 4258 jan 1 1970 es -r--r--r-- 1 root root 4076 jan 1 1970 fi -r--r--r-- 1 root root 4210 jan 1 1970 fr ====== Still, after they are added to the store, they end up with the executable bit set. I then deleted most phases of the build one by one until I could find the culprit (spoiler: it was one of the firsts: unpack). Indeed, after "unpack", the files end up with surprising permissions: ====== -rw-r--r-- 1 cabal cabal 4033 jan 1 1970 da -rwxrwxrwx 1 cabal cabal 4187 jan 1 1970 de lrwxrwxrwx 1 cabal cabal 2 jan 1 1970 de-AT -> de -rwxrwxrwx 1 cabal cabal 3865 jan 1 1970 en lrwxrwxrwx 1 cabal cabal 2 jan 1 1970 en-GB -> en lrwxrwxrwx 1 cabal cabal 2 jan 1 1970 en-US -> en -rw-r--r-- 1 cabal cabal 4258 jan 1 1970 es -rw-r--r-- 1 cabal cabal 4076 jan 1 1970 fi -rw-r--r-- 1 cabal cabal 4210 jan 1 1970 fr ====== Note how every file that is the target of a symlink is "0777", and the other regular files are "0644". It turns out that we're doing this in the "unpack" phase of the gnu-build-system: ====== ;; Make the source checkout files writable, for convenience. (for-each (lambda (f) (false-if-exception (make-file-writable f))) (find-files "."))) ====== So this explains the additional writable bit set on some of the file, but not where the executable bit comes from. The answer is in make-file-writable from (guix build utils): ====== (define (make-file-writable file) "Make FILE writable for its owner." (let ((stat (lstat file))) ;XXX: symlinks (chmod file (logior #o600 (stat:perms stat))))) ====== Since it uses lstat to get the permissions of files, whenever a symlink is encountered the target of the symlink (because chmod dereferences the link) will have its permissions changed to the ones of the symlink (777). Later when the file is copied to the store the writable bit is removed, so our target files end up with "0555" permissions. This is problematic, as files that were originally not meant to be executable will be added to the store as executable. I wonder if it ever makes sense to call "lstat" instead of "stat" in make-file-writable. Since (AFAIK) symlinks always have "777" permissions and chmod anyway cannot change the permissions on the symlink itself, I can't think of a case where using lstat would be useful. Am I missing one? An alternative to changing "lstat" to "stat" would be to skip symlinks (either within make-file-writable or in the callers). What do you think? Related commits: 6129ebddbdd306ab60bb657d627db87686d76aa0 5a64a791317d98171435eff541a835ab0d3f498c Related thread: https://issues.guix.gnu.org/43015 Kind regards, Raphaël
Raphaël Mélotte <raphael.melotte@HIDDEN>:bug-guix@HIDDEN.
Full text available.bug-guix@HIDDEN:bug#55287; Package guix.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.