[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L
From: |
Kamil Dudka |
Subject: |
Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L |
Date: |
Mon, 3 Oct 2011 16:13:40 +0200 |
User-agent: |
KMail/1.13.7 (Linux/2.6.35.11-83.fc14.x86_64; KDE/4.6.5; x86_64; ; ) |
On Mon October 3 2011 15:45:36 Bruno Haible wrote:
> Kamil Dudka wrote:
> > The commit 95f7c57 introduced an unintended change in behavior of ls -L.
> > I am attaching a patch that restores the old behavior.
>
> This patch introduces an additional lstat() system call
Yes.
> , when it is not necessary.
I disagree. ls -L does not do lstat().
> Recall that when file_has_acl is called, it gets the result of stat() or
> lstat() passed through the 'sb' argument. If it's the result of stat(),
> the user is interested in the symlink's target, so the code should call
> acl_extended_file(). If it's the result of lstat(), the user is interested
> in the symlink itself, so the code should call
> acl_extended_file_nofollow().
>
> So there are 3 cases:
> a) A non-symlink, hence acl_extended_file_nofollow and acl_extended_file
> are equivalent.
> b) A symlink, with dereferencing (stat()). Must call acl_extended_file.
> c) A symlink, without dereferencing (lstat()). Must call
> acl_extended_file_nofollow.
>
> You are using lstat() to distinguish case a) from b)+c). But it is also
> possible to inspect *sb, to distinguish case c) from a)+b).
How exactly? I do not get it.
> In fact, the code already does this, at the beginning of the function
> file_has_acl. So in case c) the big compound statement is skipped, and the
> function immediately does a "return 0". The patch that you proposed on
> 2011-04-06 and committed on 2011-07-22 therefore can only have an effect in
> the cases a) and b). In the case b) you have introduced a regression,
> that's what you've discovered now. And in the case a) - when the file is
> not a symlink: are you saying in <https://bugzilla.redhat.com/720325> that
> calling acl_extended_file on a non-symlink will trigger autofs mounts??
Yes, the getxattr syscall triggers it. lgetxattr does not.
> So, before adding more complexity to the patch of 2011-07-22, I would like
> to
> 1) understand better which file system operations triggered the autofs
> mounts, I can't really beleive that calling getxattr on a non-symlink
> will trigger autofs mounts.
That's the information I was given. As a user-space hacker, I cannot help
with providing more details about the kernel internals.
> 2) see a test case added to gnulib or coreutils.
A while ago, Jim wrote a test-case for coreutils that catches exactly the bug
that the original patch introduced.
> If you cannot come up with such a test case, I suggest to revert the patch
> of 2011-07-22.
Why? AFAIK, there has never been a test-case for the ACL detection in ls.
Kamil
- Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, (continued)
Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Jim Meyering, 2011/10/03
Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Bruno Haible, 2011/10/03
Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Bruno Haible, 2011/10/03
- Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L,
Kamil Dudka <=
- Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Kamil Dudka, 2011/10/03
- Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Bruno Haible, 2011/10/03
- Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Kamil Dudka, 2011/10/03
- Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Bruno Haible, 2011/10/03
- Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Kamil Dudka, 2011/10/03
- Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Jim Meyering, 2011/10/05
- Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Bruno Haible, 2011/10/05
- Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Jim Meyering, 2011/10/05
- Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Kamil Dudka, 2011/10/05
Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L, Kamil Dudka, 2011/10/03