+++ 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>
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.