Le 16/01/2020 à 04:21, Ken Moffat via blfs-support a écrit :
> On Wed, Jan 15, 2020 at 03:09:20PM -0700, Alan Feuerbacher via blfs-support 
> wrote:
>>
>> On 1/15/2020 1:43 PM, Pierre Labastie via blfs-support wrote:
>>> Le 15/01/2020 à 21:27, Alan Feuerbacher via blfs-support a écrit :
>>>> I just built the updated git-2.25.0 and ran the tests. The BLFS book says 
>>>> that
>>>> running them as a normal user should produce no failures, but I immediately
>>>> get this error:
>>>>
>>>> cat: version: Permission denied
>>>>
>>>> /bin/sh: GIT-BUILD-OPTIONS+: Permission denied
>>>>
>>>> But if I run the tests as root, all tests pass.
>>>>
>>>> I don't know if this is a problem.
>>>>
>>> Hmmm, Maybe you can try to figure out this one by yourself: first check who 
>>> is
>>> the owner of a "version" file, or GIT-BUILD-OPTIONS file (or file whose name
>>> begin with version or GIT-BUILD-OPTIONS), explore your build tree, checking
>>> for anything that could prevent a normal user to access the files, etc...
>>>
>>> Pierre
>>
>> In the build tree, there's a file "version" with owner "110493 5000" and
>> permissions "-rw-r----". This is the same owner as "configure". These are
>> the only files not owned by "root root". If as user lfs I "cat version" I
>> get the same error as above -- as expected, given the permissions for
>> "other". If I cat some random file with owner "root root" and permissions
>> "-rw-rw-r-", it works fine, as expected. If, as root, I "cat version" I get
>> the expected "2.25.0". I don't know what to make of this.
>>
>> What does owner "110493 5000" mean? Why would only two files have this odd
>> ownership and why is there no read permission for "other"?
> 
> I've just downloaded and extracted 2.25.0 :
> 
> ken@deluxe /tmp/git-2.25.0 $ls -l version configure
> -rwxr-x--- 1 ken users 254075 Jan 13 18:46 configure
> -rw-r----- 1 ken users      7 Jan 13 18:46 version
> 
> Note that this is *all* as my regular user and without a previously
> extracted version.
> 
>>
>> For GIT-BUILD-OPTIONS the owner is "root root" with permissions
>> "-rw-r--r--". I would guess that, since bash is given this file to execute,
>> and there is no "x" in the permissions, we get the "permission denied"
>> error. But if this is part of the testing, why does whatever software that
>> makes the build tree not add "x" to the permissions?
>>
> 
> After make -j8 :
> 
> ken@deluxe /tmp/git-2.25.0 $ls -l GIT-*
> -rw-r--r-- 1 ken users 323 Jan 16 03:10 GIT-BUILD-OPTIONS
> -rw-r--r-- 1 ken users 550 Jan 16 03:10 GIT-CFLAGS
> -rw-r--r-- 1 ken users   2 Jan 16 03:10 GIT-LDFLAGS
> -rw-r--r-- 1 ken users  90 Jan 16 03:10 GIT-PERL-DEFINES
> -rw-r--r-- 1 ken users  62 Jan 16 03:10 GIT-PERL-HEADER
> -rw-r--r-- 1 ken users  85 Jan 16 03:10 GIT-PREFIX
> -rw-r--r-- 1 ken users  32 Jan 16 03:10 GIT-PYTHON-VARS
> -rw-r--r-- 1 ken users 111 Jan 16 03:10 GIT-SCRIPT-DEFINES
> -rw-r--r-- 1 ken users  11 Jan 16 03:10 GIT-USER-AGENT
> -rw-r--r-- 1 ken users  21 Jan 16 03:10 GIT-VERSION-FILE
> -rwxr-xr-x 1 ken users 752 Jan 13 18:46 GIT-VERSION-GEN
> 
> And after make -j8 test:
> 
> make aggregate-results
> make[3]: Entering directory '/tmp/git-2.25.0/t'
> for f in 'test-results'/t*-*.counts; do \
>       echo "$f"; \
> done | '/bin/sh' ./aggregate-results.sh
> fixed   0
> success 20320
> failed  0
> broken  236
> total   21011
> 
> I can only assume that you perhaps extracted, or configured, or ran
> make, as a different user.  For me, configure is extracted with my
> ownership, and the other file is generated during the build.  But
> I've no idea how that uid and gid were assigned.  I think I've seen
> "odd" ownership on files where a tarball or maybe a zip file has
> come from a strange source (probably OSX, certainly zip files for
> fonts on OSX have all manner of wirdness in them), but this ought to
> be a "created on linux, downloaded from kernel.org" tarball.

Visibly, Alan has extracted the tarball as root, then tried to run the tests
as user (after running configure and make as root, I guess, otherwise the
permission problem would have shown up earlier)... When tar extracts a file as
user root, it keeps the original user:group for all files (unless passing
"--no-same-owner"). So the uid/gid that Alan sees are just the ones of the git
packager. On "recent" systems, uid and gid are 64 bit. So it is not amazing to
find an uid of 110493 coming from a system (the kernel machines) with plenty
of users and many activities (that is, many groups too).

Alan, extract, configure and make as user (and make tests as user unless
otherwise instructed), then become root for make install (or when instructed,
we try to be careful adding "as the root user" for any command needing root
privs).

Pierre

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to