View Bug Activity | Format For Printing
pathconf(path,_PC_CHOWN_RESTRICTED)always returns POSIX_CHOWN_RESTRICTED even if the filesystem where path is located is configured to allow unrestricted chown. This seems to be an inconsistency between kernel, glibc and LSB. although the Linux syscall chown allows unpriviliged users to chown files if the filesystem does, LSB 3.2 core generic para. 13.4.79 mandates that POSIX_CHOWN_RESTRICTED be defined as 1. This variable should be undefined because that feature definitely depends on filesystem and need not be the same for all fs on a host. But even if POSIX_CHOWN_RESTRICTED were undefined, pathconf would return the wrong value since it always returns -1 in that case. I checked today http://sources.redhat.com/cgi- bin/cvsweb.cgi/libc/sysdeps/posix/?cvsroot=glibc, pathconf.c is the same since 2003, I tested with 2.3.5. Filesystems with unrestricted chown can be local (XFS with /proc/sys/fs/xfs/restrict_chown=0) or NFS mounted.
When the pathconf code was written xfs didn't exist for Linux. I've changed it. What LSB is of no relevance, it has nothing whatsoever to do with glibc.
Thanks for the patch. When I look at the explanation in posix/unistd.h If any is defined as other than -1, the corresponding option is true for all files. If a symbol is not defined at all, the value for a specific file can be obtained from `pathconf' and `fpathconf'. I wonder whether _POSIX_CHOWN_RESTRICTED shouldn't be undefined instead of being set to 0. XFS was just an example. Linux also allows unrestricted chown on NFS mounted filesystems if the NFS server is configured so. It's certainly difficult for glibc to handle such cases as long as the kernel does not provide a query interface for pathconf. Perhaps errno could be set to EINVAL (in the meaning of not implemented) in such cases.