From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aWFY3-0005Yz-0k for mharc-grub-devel@gnu.org; Wed, 17 Feb 2016 22:46:35 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWFXz-0005Wx-9e for grub-devel@gnu.org; Wed, 17 Feb 2016 22:46:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWFXw-0002aA-34 for grub-devel@gnu.org; Wed, 17 Feb 2016 22:46:31 -0500 Received: from mail-lf0-x22c.google.com ([2a00:1450:4010:c07::22c]:36031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWFXv-0002a5-Qt for grub-devel@gnu.org; Wed, 17 Feb 2016 22:46:28 -0500 Received: by mail-lf0-x22c.google.com with SMTP id 78so24027405lfy.3 for ; Wed, 17 Feb 2016 19:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=A02CEB+zWeKHHYdrn9iXc8mCG9VmqkFvHWds/kjp6XE=; b=aY1MPRel5E/dVQ9Ah+0uOgCOoSbBlWW1V/gnAbElLvOPKppmfQX0DkNv7sLPsb5UKO DeGDCS2XH05Wg2e+zHQ7h516nlgrSbv6S2u0a3/vjaYydIEBEFRIwfFr4miA2RuXYOyu sRsY9decB+YtOcnhv0ropxYP5ohbxQdCmYkx3HJG7EKGVh15pqlXTNW2oGj7tD/CdBQ1 XKcnmXsTsI5F6sadjiKej5SuzsvSBCXuCT6ENUzFwLRLsafXixr49Go1NsEcXM1t/euj b6H/c2sMyL3h2nAqsUEYa9zcc87blkRvFd4WLbEekZ1asCm6fJVBkf5ggDCl/Eejq4R/ aqeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=A02CEB+zWeKHHYdrn9iXc8mCG9VmqkFvHWds/kjp6XE=; b=EOaA1IbnwnijWEi8mZP/zGvUMpzcyUAsp2aYp6PZfFRsLrtVa1lA0jcTt4YbD28XfW tzGwFkHdRKjTs67PRtCXvbK/e5Xf6KyFYtYNZwS6hij+s0cWN5FeOZ+7ttzIXg1YLP+I QNs7+D1pN4AfBErl3z/DMl+X21QNQ1g2h6APETkAeoH6+rgQj2BPAMpOKIPd+FMJMl0q Ni1pY4L741rBjnHbJwrKuoFljuxvBC2i2OxfdCjj6N1ecYeOUDBCrPKRTypoZWeWSrgc xpOGYNtcnz86CLBUfgg+BNQkthW3p2i+uiQyBFg9LqhorgPklNbsFpRmbr2rwHJ0pPD2 5XWA== X-Gm-Message-State: AG10YOTU0rrJk77Y9JzNn6fdk125NAWjENjp2KouIjTp6iHGoRq1lZYf7vs35+X8vshLDQ== X-Received: by 10.25.209.83 with SMTP id i80mr2281276lfg.74.1455767186907; Wed, 17 Feb 2016 19:46:26 -0800 (PST) Received: from [192.168.1.41] (ppp109-252-76-159.pppoe.spdop.ru. [109.252.76.159]) by smtp.gmail.com with ESMTPSA id s75sm641575lfs.21.2016.02.17.19.46.25 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Feb 2016 19:46:25 -0800 (PST) Subject: Re: Behavior of file test operations on symlinks To: grub-devel@gnu.org References: <56C4A305.8010206@gmail.com> From: Andrei Borzenkov Message-ID: <56C53E91.5020705@gmail.com> Date: Thu, 18 Feb 2016 06:46:25 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::22c X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 03:46:32 -0000 17.02.2016 23:19, Alan Dunn пишет: > On Wed, Feb 17, 2016 at 8:42 AM, Andrei Borzenkov > wrote: > >> 17.02.2016 03:34, Alan Dunn пишет: >>> Hi folks, >>> >>> Apologies if the following has already come up on this list; I looked for >>> it and could not find any mention of it. >>> >>> I noticed that in a GRUB script "[ -f ]" >> evaluates >>> to true. This is unlike the behavior of the "test" binary, in which it >>> returns false: most file test operations dereference their symlinks >>> recursively (i.e., strace on Linux reveals they use stat, which does >>> this). By contrast, "[ -s ]" evaluates to false, >>> which seems inconsistent since if the file exists by -f, then it seems >> like >>> -f is referring to the symlink itself, which has non-zero file size. >>> >> >> It looks rather side effect of implementation which looks for directory >> entry. >> >> It is straightforward to fix it by just trying to grub_file_open() which >> fails in this case. But the interesting question is semantic of both >> tests with mandatory signature checking in place. I.e. if signature for >> a file is invalid, should "test -s" and "test -f" still report true? I >> suppose yes, because file still exists. >> >>> I was curious whether there is some motivation with respect to any >>> deviations that GRUB has in interpreting file test operations in >> comparison >>> to the "test" binary, or whether this is considered a bug/thing that >> should >>> be improved in the documentation. The GRUB manual ( >>> http://git.savannah.gnu.org/cgit/grub.git/tree/docs/grub.texi) only >>> indicates that -f tests whether the "file exists and is not a directory" >> >> Well, current behavior is compliant with this description (symlink does >> exist and it is not directory), it is just not very useful in practice. >> Actually implementing "test -h" is pretty trivial. >> >>> without specifying the symlink behavior (unlike "man test"). >>> >> >> I vote for changing it to follow symlink. Anyone has argument to keep >> current behavior? >> > > If I were going to design GRUB's behavior, I would make all file-related > tests that GRUB implements (-d, -e, -f, -s, -nt, -ot) follow symlinks, like > test in coreutils does, for consistency. If that sounds reasonable to the > list, I'm happy to try to produce such a patch. Offhand, it seems like the > basic strategy would be to modify get_fileinfo (in > grub-core/commands/test.c) to follow symlinks. > It means reimplementing symlink traversal yet again and doing it pretty inefficiently. Storing mtime in struct grub_file and using grub_file_open seems to be the least evil.