* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
@ 2020-09-18 23:55 ` mark at klomp dot org
2020-09-24 9:54 ` ludo at gnu dot org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: mark at klomp dot org @ 2020-09-18 23:55 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mark at klomp dot org
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
2020-09-18 23:55 ` [Bug dynamic-link/26634] " mark at klomp dot org
@ 2020-09-24 9:54 ` ludo at gnu dot org
2020-09-24 10:29 ` fweimer at redhat dot com
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ludo at gnu dot org @ 2020-09-24 9:54 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
--- Comment #1 from Ludovic Courtès <ludo at gnu dot org> ---
Created attachment 12861
--> https://sourceware.org/bugzilla/attachment.cgi?id=12861&action=edit
Patch to skip 'stat' when the audit module provided a different file name
This attached patch provides a fix/workaround: it leaves directory information
unchanged (skips the incorrect 'stat' calls) when 'open_verify' returns -1 and
'changed_by_audit == true'.
I confirm that it solves the initial case reported at
<https://issues.guix.gnu.org/43491>.
I this approach sounds reasonable, I can formally submit it to libc-alpha--let
me know!
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
2020-09-18 23:55 ` [Bug dynamic-link/26634] " mark at klomp dot org
2020-09-24 9:54 ` ludo at gnu dot org
@ 2020-09-24 10:29 ` fweimer at redhat dot com
2020-09-24 13:31 ` ludo at gnu dot org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: fweimer at redhat dot com @ 2020-09-24 10:29 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
CC| |fweimer at redhat dot com
--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
Is there an actual bug here? The loader caches information that search path
entries do not exist. It is likely that this information will be useful for
further library loading. So this does not even seem to be a performance bug.
Or is there an observable behavioral difference?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
` (2 preceding siblings ...)
2020-09-24 10:29 ` fweimer at redhat dot com
@ 2020-09-24 13:31 ` ludo at gnu dot org
2020-09-24 13:35 ` fweimer at redhat dot com
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ludo at gnu dot org @ 2020-09-24 13:31 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
--- Comment #3 from Ludovic Courtès <ludo at gnu dot org> ---
(In reply to Florian Weimer from comment #2)
> Is there an actual bug here? The loader caches information that search path
> entries do not exist. It is likely that this information will be useful for
> further library loading. So this does not even seem to be a performance bug.
>
> Or is there an observable behavioral difference?
Yes: when an audit module is used, the loader potentially stats the wrong
directory (the "original" one instead of that returned by the audit module),
and thus caches wrong information about search path entries.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
` (3 preceding siblings ...)
2020-09-24 13:31 ` ludo at gnu dot org
@ 2020-09-24 13:35 ` fweimer at redhat dot com
2020-09-24 13:50 ` ludo at gnu dot org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: fweimer at redhat dot com @ 2020-09-24 13:35 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Ludovic Courtès from comment #3)
> (In reply to Florian Weimer from comment #2)
> > Is there an actual bug here? The loader caches information that search path
> > entries do not exist. It is likely that this information will be useful for
> > further library loading. So this does not even seem to be a performance bug.
> >
> > Or is there an observable behavioral difference?
>
> Yes: when an audit module is used, the loader potentially stats the wrong
> directory (the "original" one instead of that returned by the audit module),
> and thus caches wrong information about search path entries.
Sorry, since the search path contains only the name without /PREFIX, probing
without /PREFIX seems like the right thing to do to me. What am I missing?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
` (4 preceding siblings ...)
2020-09-24 13:35 ` fweimer at redhat dot com
@ 2020-09-24 13:50 ` ludo at gnu dot org
2020-09-24 13:56 ` fweimer at redhat dot com
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ludo at gnu dot org @ 2020-09-24 13:50 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
--- Comment #5 from Ludovic Courtès <ludo at gnu dot org> ---
(In reply to Florian Weimer from comment #4)
> Sorry, since the search path contains only the name without /PREFIX, probing
> without /PREFIX seems like the right thing to do to me. What am I missing?
'open_verify' checks /PREFIX/xyz/libfoo.so and returns -1. Then the caller
stats /xyz, determines that it's ENOENT, and marks the entry as nonexisting.
This is inconsistent: /PREFIX/xyz may well exist and thus, had we statted it,
we would not have marked the entry as nonexisting.
Does that make sense?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
` (5 preceding siblings ...)
2020-09-24 13:50 ` ludo at gnu dot org
@ 2020-09-24 13:56 ` fweimer at redhat dot com
2020-09-24 14:11 ` ludo at gnu dot org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: fweimer at redhat dot com @ 2020-09-24 13:56 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Ludovic Courtès from comment #5)
> (In reply to Florian Weimer from comment #4)
> > Sorry, since the search path contains only the name without /PREFIX, probing
> > without /PREFIX seems like the right thing to do to me. What am I missing?
>
> 'open_verify' checks /PREFIX/xyz/libfoo.so and returns -1. Then the caller
> stats /xyz, determines that it's ENOENT, and marks the entry as nonexisting.
>
> This is inconsistent: /PREFIX/xyz may well exist and thus, had we statted
> it, we would not have marked the entry as nonexisting.
I assume (based on my limited understanding of the code), that it stats /xyz
and marks /xyz as non-existing. The search paths do not contain /PREFIX
because that was added by la_objsearch. open_verify does not change the
incoming pathname buffer.
Are you observing something different?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
` (6 preceding siblings ...)
2020-09-24 13:56 ` fweimer at redhat dot com
@ 2020-09-24 14:11 ` ludo at gnu dot org
2020-09-24 14:14 ` fweimer at redhat dot com
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ludo at gnu dot org @ 2020-09-24 14:11 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
--- Comment #7 from Ludovic Courtès <ludo at gnu dot org> ---
(In reply to Florian Weimer from comment #6)
> I assume (based on my limited understanding of the code), that it stats /xyz
> and marks /xyz as non-existing. The search paths do not contain /PREFIX
> because that was added by la_objsearch. open_verify does not change the
> incoming pathname buffer.
>
> Are you observing something different?
No, what you're writing is correct.
However, the effect is that /PREFIX/xyz will never be searched again because of
this inconsistency, even though it possibly should. To me this is a bug
because the audit module's rewrite is not honored.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
` (7 preceding siblings ...)
2020-09-24 14:11 ` ludo at gnu dot org
@ 2020-09-24 14:14 ` fweimer at redhat dot com
2020-09-24 14:37 ` ludo at gnu dot org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: fweimer at redhat dot com @ 2020-09-24 14:14 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
--- Comment #8 from Florian Weimer <fweimer at redhat dot com> ---
Sorry, this is not what I meant. I expect that /xyz will never be searched
again. But that is fine, because it does not actually exist?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
` (8 preceding siblings ...)
2020-09-24 14:14 ` fweimer at redhat dot com
@ 2020-09-24 14:37 ` ludo at gnu dot org
2020-09-24 14:39 ` fweimer at redhat dot com
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ludo at gnu dot org @ 2020-09-24 14:37 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
--- Comment #9 from Ludovic Courtès <ludo at gnu dot org> ---
(In reply to Florian Weimer from comment #8)
> Sorry, this is not what I meant. I expect that /xyz will never be searched
> again. But that is fine, because it does not actually exist?
To me it's not OK: the audit module said "look under /PREFIX/xyz" so what
matters is whether /PREFIX/xyz exists, not whether /xyz exists.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
` (9 preceding siblings ...)
2020-09-24 14:37 ` ludo at gnu dot org
@ 2020-09-24 14:39 ` fweimer at redhat dot com
2020-09-24 15:01 ` ludo at gnu dot org
2020-09-24 15:04 ` fweimer at redhat dot com
12 siblings, 0 replies; 14+ messages in thread
From: fweimer at redhat dot com @ 2020-09-24 14:39 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
--- Comment #10 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Ludovic Courtès from comment #9)
> To me it's not OK: the audit module said "look under /PREFIX/xyz" so what
> matters is whether /PREFIX/xyz exists, not whether /xyz exists.
But there is no search path entry for /PREFIX/xyz, so there is nothing to cache
there. Let me think about it.
Maybe we should disable negative caching if la_objsearch is present altogether.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
` (10 preceding siblings ...)
2020-09-24 14:39 ` fweimer at redhat dot com
@ 2020-09-24 15:01 ` ludo at gnu dot org
2020-09-24 15:04 ` fweimer at redhat dot com
12 siblings, 0 replies; 14+ messages in thread
From: ludo at gnu dot org @ 2020-09-24 15:01 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
--- Comment #11 from Ludovic Courtès <ludo at gnu dot org> ---
(In reply to Florian Weimer from comment #10)
> (In reply to Ludovic Courtès from comment #9)
> > To me it's not OK: the audit module said "look under /PREFIX/xyz" so what
> > matters is whether /PREFIX/xyz exists, not whether /xyz exists.
>
> But there is no search path entry for /PREFIX/xyz, so there is nothing to
> cache there. Let me think about it.
>
> Maybe we should disable negative caching if la_objsearch is present
> altogether.
Yes, I agree. The patch I attached earlier does that.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug dynamic-link/26634] ld.so stats raw file names, bypassing the audit module
2020-09-18 21:44 [Bug dynamic-link/26634] New: ld.so stats raw file names, bypassing the audit module ludo at gnu dot org
` (11 preceding siblings ...)
2020-09-24 15:01 ` ludo at gnu dot org
@ 2020-09-24 15:04 ` fweimer at redhat dot com
12 siblings, 0 replies; 14+ messages in thread
From: fweimer at redhat dot com @ 2020-09-24 15:04 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=26634
--- Comment #12 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Ludovic Courtès from comment #11)
> > Maybe we should disable negative caching if la_objsearch is present
> > altogether.
>
> Yes, I agree. The patch I attached earlier does that.
Only if la_objsearch changed the path. I was thinking about doing it more
generally.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread