Re: [BUG] xfs_quota: can't handle the users managed by LDAP

[Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>]

(2012/11/28 6:05), Dave Chinner wrote:
> On Tue, Nov 27, 2012 at 04:27:34PM +0900, Satoru Takeuchi wrote:
>>>>>>> Current xfs_quota (I pulled xfsprogs today) seems not be able to the users
>>>>>>> managed by LDAP. There is no patch since I'm not good at LDAP and don't know
>>>>>>> the root cause yet ;-(
>>>>>>>
>>>>>>> Step to reproduce(in this case, "sat" is the user managed by LDAP):
>>>>>>> ===============================================================================
>>>>>>> # uname -r
>>>>>>> 3.7.0-rc5
>>>>>>> # mount -o loop,usrquota xfs.img mnt
>>>>>>> # xfsprogs/quota/xfs_quota -xc "limit bsoft=10M bhard=10M sat" /dev/loop0
>>>>>>> xfs_quota: invalid user name: sat                                          # denied
>>>>>>> # su sat
>>>>>>> $                                                                          # But this user acutally exists.
>>>>>>> ===============================================================================
> .....
> 
>> So there is a problem in "report" subcommand. Refer to report_without_U.log,
>> I found "quotactl(Q_XGETQUOTA|GRPQUOTA, ...) is only called for local users
>> and it's because that getpwent() only returned only local users.
> 
> Yes, it appears from the strace that glibc is only reading
> /etc/passwd and not querying the ldap server.
> 
>> open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
>> fstat(3, {st_mode=S_IFREG|0644, st_size=1724, ...}) = 0
>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f851afee000
>> read(3, "#¥n# /etc/nsswitch.conf¥n#¥n# An ex"..., 4096) = 1724
>> read(3, "", 4096)                       = 0
>> close(3)                                = 0
> ...
>> open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
> ...
>> open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
>> fstat(3, {st_mode=S_IFREG|0644, st_size=2005, ...}) = 0
>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f851afee000
>> lseek(3, 0, SEEK_CUR)                   = 0
>> read(3, "root:x:0:0:root:/root:/bin/bash¥n"..., 4096) = 2005
>> quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/loop0", 0, {version=1, flags=XFS_USER_QUOTA, fieldmask=0, id=0, blk_hardlimit=0, blk_softlimit=0, ino_hardlimit=0, ino_softlimit=0, bcount=0, icount=3, ...}) = 0
> 
> As you can see, it only dynamically loads the local files name
> service library, not the ones that do ldap lookups.
> 
> Can you run ldd on the test binary you had and on xfs_quota to see
> if they are linked against the same libraries?

I ran ldd on the test binary and found that I built it on i686
machine and the test machine is x86_64. So the test binary
couldn't find the suitable 32 bit nss library on the test machine.
I found the test binary built on the test machine works the same
as xfs_quota.

             | build machine | getpwnam  | getpwent
=============+===============+===========+==========
test binary  | 32 bit        | NG        | NG
             | 64 bit        | OK        | NG
-------------+---------------+-----------+----------
xfs_quota    | 64 bit        | OK        | NG
-------------+---------------+-----------+----------

Since the test binary(64bit) and xfs_quota load the same
nss library and have the same behavior, it's apparently
not the xfs_quota problem but the LDAP/libnss related problem.

I will dig this problem more as the LDAP/libnss perspective.

Thank you very much for helping me, Dave.

Satoru

> 
> Other than that, I've go no idea why glibc would be behaving
> differently for the same library call from different binaries.
> it tends to imply a problem outside of xfs_quota, but I know close
> to nothing about LDAP and the glibc name services, so I don't know
> what more I can do to help here....
> 
> Cheers,
> 
> Dave.
> 


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs