Bug 1869624

Summary:	coreutils: test -w broken
Product:	[Fedora] Fedora	Reporter:	Florian Bezdeka <florian>
Component:	coreutils	Assignee:	Kamil Dudka <kdudka>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	admiller, jamartis, jarodwilson, kdudka, kzak, ooprala, ovasik, p, sebastian.kisela, svashisht
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-08-24 08:44:21 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Florian Bezdeka 2020-08-18 11:37:34 UTC

Description of problem:
test -w is returning a wrong return code


Version-Release number of selected component (if applicable):
8.32-11.fc33

How reproducible:


Steps to Reproduce:
1. mkdir -p /tmp/foo
2. test -w /tmp/foo; echo $?

Actual results:
1

Expected results:
0

Additional info:

Comment 1 Kamil Dudka 2020-08-18 12:43:25 UTC

I guess you are using a shell built-in rather than the program installed by coreutils.  Anyway, did you check permissions of the directory?

$ ls -dl /tmp/foo

Comment 2 Florian Bezdeka 2020-08-18 14:36:26 UTC

Hi there,

I really thought that I have narrowed this thing down to the right component, but after some additional investigations I'm not sure anymore.

First of all, maybe this bug should be moved to another component / package. Best guess is bash for now, but stay tuned, it's not easy to find the right one...

Scenario:
We are running a Fedora 33 docker (docker is really important here...) container hosted on Debian 10 for building some RPM packages. The following happens:

docker pull fedora:33
docker run -v $(pwd):/this/:rw --rm -t -i fedora:33 bash
[root@0316b /]# mkdir /tmp/pretest
[root@0316b /]# test -w /tmp/pretest; echo $?
0
[root@0316b /]
[root@0316b /]# ./do-package-building
[root@0316b /]
[root@0316b /]# test -w /tmp/posttest; echo $?
0
[root@0316b /]# bash
[root@0316b /]# test -w /tmp/posttest; echo $?
1
[root@0316b /]#
[root@0316b /]# ls -al /tmp/
drwxr-xr-x  2 root root 4096 Aug 18 13:46 posttest
drwxr-xr-x  2 root root 4096 Aug 18 13:43 pretest

If we skip the ./do-package-building step above, everything works as expected. This is why we are now reviewing them again. Maybe it is related to the Fedora 33 rawhide splitting or something similar. Some packages will be installed during this step.
Starting another shell process using "bash" is necessary.

The problem can not be reproduced at all when running the container on podman hosted on Fedora 32. It does not matter if our own scripts are involved or not.

Maybe we should just wait some days and try again...

Comment 3 Kamil Dudka 2020-08-18 15:48:48 UTC

Thank you for sharing the context with us!

There is a very similar problem reported for bash: bug #1869597

It seems to be caused by a systemd/glibc issue: bug #1869030

Comment 4 Kamil Dudka 2020-08-24 08:44:21 UTC


*** This bug has been marked as a duplicate of bug 1869030 ***

Comment 5 Florian Bezdeka 2020-11-17 09:39:52 UTC

The problem is back after several weeks / months now. This time Fedora 34 / rawhide is affected only.

Comment 6 Kamil Dudka 2020-11-17 10:47:31 UTC

Yes, my CI jobs running on Fedora Rawhide were also affected by this bug last week.  I had to use my own build of glibc with the problematic change reverted to make my CI jobs green again.