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?
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.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
