From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aW5Bn-0006wi-FT for mharc-grub-devel@gnu.org; Wed, 17 Feb 2016 11:42:55 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aW5Bk-0006vw-2k for grub-devel@gnu.org; Wed, 17 Feb 2016 11:42:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aW5Bg-0002W2-QV for grub-devel@gnu.org; Wed, 17 Feb 2016 11:42:51 -0500 Received: from mail-lb0-x230.google.com ([2a00:1450:4010:c04::230]:34777) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aW5Bg-0002Vl-Ia for grub-devel@gnu.org; Wed, 17 Feb 2016 11:42:48 -0500 Received: by mail-lb0-x230.google.com with SMTP id of3so12913048lbc.1 for ; Wed, 17 Feb 2016 08:42:48 -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=NMHZ7KAYx/T8b2dg6tNcjtkhAdTXFAwdYbdImmeNYco=; b=NQHrZTx0H8SLDVsePMdpxLBoAWh0bNa4IRPrM7eonRrp/w82TWfw6TxqjycohOP+b5 4CJ7oicgUb5FQjXixIHInhPtzcTyEIoyxmtEVvLyF0auC1LGq2Lspse+bJgaJGZmcx5I ozUNjUzdpNZGYSqdzLNQbRUVJvxWS2ujJ8Ua0m7xXQm/RA0IXZTyFYu7GuJwhQTHd3dv W1kz3yGBKGk5NUH3ju1vfsnkMoqLqjFjgduA0qAUJHmMzlJF4t85rU1S/hidRbEiJMbf +Ojx2AoBNezl0KPGQALG+3lImaewv27EL3nGGaCDWzzocJKVAUgz7K4xBxEhYpIlM2g8 Devg== 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=NMHZ7KAYx/T8b2dg6tNcjtkhAdTXFAwdYbdImmeNYco=; b=XDZfcB2bEGXkocssnePN5lJ4me7sQcQxK+1t7aGfQQZfK+RHQCWVAzTUn4nVOwjV7d ErgFonCSTDOKR2l3Iw9Ub4W/3iYUezmdiVOl+hx70pcQYFAEI7rNhKMpeA6oJgjDnKX9 2cZjqI1NO7wwc7mBUMnrFtqTXFjBSRfQZIqmlzmSeA36CwSKTo9lOrBt6WKFl+2xhcAv Up8jepcOGnezNLeLyU6s1DLjASqyqIcjxna7mY4FRtnMHLl+s5V0o7HxsbOz23482MSA 6Rpyk4rKrOAnCTu6SJeoE1cgIHV6lSdUpddIipbqflbiKxwfv7Ukm6bVprxc/xBlj1PH OJfg== X-Gm-Message-State: AG10YOSaTHGX8+RIjHY11Plo3o9FWAOEQbeuch3AQQ3MRjci8tQAmHvDwdruGZUkzvuuFg== X-Received: by 10.112.160.232 with SMTP id xn8mr1114434lbb.22.1455727367469; Wed, 17 Feb 2016 08:42:47 -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 xf10sm316752lbb.23.2016.02.17.08.42.46 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Feb 2016 08:42:46 -0800 (PST) Subject: Re: Behavior of file test operations on symlinks To: The development of GNU GRUB References: From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <56C4A305.8010206@gmail.com> Date: Wed, 17 Feb 2016 19:42:45 +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:c04::230 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: Wed, 17 Feb 2016 16:42:53 -0000 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?