This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 977870 - pathconf and fpathconf fail to return _PC_CHOWN_RESTRICTED for a directory
pathconf and fpathconf fail to return _PC_CHOWN_RESTRICTED for a directory
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
19
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Siddhesh Poyarekar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-25 09:47 EDT by Siddhesh Poyarekar
Modified: 2016-11-24 07:10 EST (History)
10 users (show)

See Also:
Fixed In Version: glibc-2.17-11.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 924102
Environment:
Last Closed: 2013-06-29 14:05:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Siddhesh Poyarekar 2013-06-25 09:47:04 EDT
+++ This bug was initially created as a clone of Bug #924102 +++

Description of problem:

On RHEL7 I can see a behavior different from Fedora18 or RHEL6.
(f)pathconf fails to return _PC_CHOWN_RESTRICTED setting for a common directory. 

# ./a.out /etc 6
post:: No such file or directory
errno = 2
res = 1

on F18:

# ./a.out /etc 6
post:: Success
errno = 0
res = 1

However on RHEL7 it works for some (special) dirs:

# ./a.out /proc 6
post:: Success
errno = 0
res = 1

I am using following test program:

# cat test.c
#include <unistd.h>
#include <stdio.h>
#include <errno.h>

int main(int argc, char *argv[]) {

  long res;

  //res = pathconf("/tmp/olver/fs_meta_access_scenario", atoi(argv[1]));
  res = pathconf(argv[1], atoi(argv[2]));

  perror("post:");
  printf("errno = %d\n", errno);
  printf("res = %lu\n", res);
}



Version-Release number of selected component (if applicable):
RHEL7 alpha3 compose (but the bug is on previous versions too)
# rpm -q glibc kernel
glibc-2.16-28.el7.x86_64
kernel-3.7.0-0.36.el7.x86_64

How reproducible:
alwyas

Steps to Reproduce:
1. see above

--- Additional comment from Karel Srot on 2013-03-21 04:06:23 EDT ---

This is also a regression, test program is working fine on RHEL7 compose 20121217.0 with

# rpm -q kernel glibc
kernel-3.6.0-0.29.el7.x86_64
glibc-2.16-24.el7.x86_64

# ./a.out /etc 6
post:: Success
errno = 0
res = 1

--- Additional comment from Karel Srot on 2013-03-21 04:12:31 EDT ---

Since it is working fine on F18 with glibc version equal to the one in RHEL7 I have a suspicion it might be a kernel bug. Anyway, pls. review and reassign to a proper component.

--- Additional comment from Siddhesh Poyarekar on 2013-03-25 06:44:09 EDT ---

It's probably because the latest compose installs xfs as the default filesystem (based on the one-off test I did on s390x).  The xfs test looks at the value of /proc/sys/fs/xfs/restrict_chown to decide on the return value for _PC_CHOWN_RESTRICTED.  That sysctl was removed a long time ago (2008), so checking for it is of no use any more.

The simple way to fix this is to set errno to 0 if opening that sysctl file fails, but I wonder if the value of errno should be read to make any conclusions on success.  I'd say that the value of errno is not defined on success for pathconf or fpathconf.  It is only defined when the return value is -1.  It's unchanged for unlimited and it reflects the error if there is one.

--- Additional comment from Karel Srot on 2013-03-25 10:17:15 EDT ---

Thank you. I can confirm that the problem appeared because of XFS filesystem. That also explains why it works on Fedora 18 which uses ext4.

--- Additional comment from Karel Srot on 2013-03-26 03:11:33 EDT ---

Was this bug report forwarded to glibc upstream? If so, could you please a link? Thank you in advance.

--- Additional comment from Siddhesh Poyarekar on 2013-03-26 03:49:18 EDT ---

I haven't forwarded it upstream yet.  I'm keeping the needinfo on Carlos since I'd like to hear his take on whether the application is justified in expecting an unchanged errno on a valid value.  Like I mentioned, the patch itself is trivial and I can post it within a day if needed.

--- Additional comment from Karel Srot on 2013-03-27 03:59:25 EDT ---

Upstream bug report: http://sourceware.org/bugzilla/show_bug.cgi?id=15305

From https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3763#c8

<snip>
Jeff Licquia 2013-03-26 16:47:35 UTC 

I've confirmed that this is a bug in glibc when pathconf or fpathconf is
pointed at an XFS filesystem.

From http://pubs.opengroup.org/onlinepubs/009695399/functions/pathconf.html,
describing a non-error condition:

"Otherwise, pathconf() or fpathconf() shall return the current variable value
for the file or directory without changing errno."

This is the condition being tested by olver-core in this case.  But errno will
almost certainly be changed by glibc when the open fails on the /proc file, as
discovered by Red Hat
</snip>

--- Additional comment from Siddhesh Poyarekar on 2013-03-28 01:11:29 EDT ---

OK, I'll fix it then.

--- Additional comment from Carlos O'Donell on 2013-03-28 11:00:30 EDT ---

Siddhesh,

I agree with Jeff Licquia. 

The most recent POSIX 2008 (http://pubs.opengroup.org/onlinepubs/9699919799/functions/pathconf.html) still has the same language, namely that errno must not be changed, that is not the same as saying errno is undefined.

I wonder if there are any cases where __statfs() could fail, and set errno when it shouldn't, but in all the cases I can think it means that you failed to have the permissions to do the stat and thus may set errno. If __statfs() doesn't fail then it won't touch errno, which works, and the only problem is the open_not_cancel_2(), read_not_cancel() and close_not_cancel_no_status() for XFS. If I had to fix this I'd just save and restore the errno value while trying to make function calls that might set errno.

--- Additional comment from Siddhesh Poyarekar on 2013-03-28 23:56:17 EDT ---

(In reply to comment #10)
> I wonder if there are any cases where __statfs() could fail, and set errno
> when it shouldn't, but in all the cases I can think it means that you failed
> to have the permissions to do the stat and thus may set errno. If __statfs()
> doesn't fail then it won't touch errno, which works, and the only problem is
> the open_not_cancel_2(), read_not_cancel() and close_not_cancel_no_status()
> for XFS. If I had to fix this I'd just save and restore the errno value
> while trying to make function calls that might set errno.

Yes, that's what I intend to do.  In addition to this, I plan to add an #ifdef around the sysctl bits so that in (the distant) future if we decide to drop support for kernels older than 2.6.29, we will remove this code.

--- Additional comment from Siddhesh Poyarekar on 2013-05-15 09:37:17 EDT ---

Fixed upstream:

commit d755bba40f880c01ced8740a26fecc85534454b9
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Wed Apr 3 10:56:45 2013 +0530

    Preserve errno across _PC_CHOWN_RESTRICTED call on XFS
    
    Fix BZ #15305.
    
    On kernel versions earlier than 2.6.29, the Linux kernel exported a
    sysctl called restrict_chown for xfs, which could be used to allow
    chown to users other than the owner.  2.6.29 removed this support,
    causing the open_not_cancel_2 to fail and thus modify errno.  The fix
    is to save and restore errno so that the caller sees it as unmodified.
    
    Additionally, since the code to check the sysctl is not useful on
    newer kernels, we add an ifdef so that in future the code block gets
    rmeoved completely.
Comment 1 Fedora Update System 2013-06-25 13:31:08 EDT
glibc-2.17-11.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/glibc-2.17-11.fc19
Comment 2 Fedora Update System 2013-06-26 13:09:35 EDT
Package glibc-2.17-11.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.17-11.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-11737/glibc-2.17-11.fc19
then log in and leave karma (feedback).
Comment 3 Fedora Update System 2013-06-29 14:05:42 EDT
glibc-2.17-11.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.