From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 93B253889E21; Fri, 17 Feb 2023 13:55:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 93B253889E21 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676642159; bh=ZpyDJQqw9DRAVF70CUj1v6YnVJWyi6zbrzs1XodlqxQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bp4txpeOu3QYYY8S5tc46cy5kObvPgXjVJVLL4pOqmboxEsWJcwYA8slV/ErILjii 4DC5qq542FwKlIc9GeWr6MmHEn7suYvU68Mgv4ybF9e36PbxKj4SkeCUpk54tT9YDb 0uSDCZn+XQPwUopm9m/haT0Pv/Lavqdf6mQCAR3g= From: "stsp at users dot sourceforge.net" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30127] [rfe]: enable ld audit at run-time Date: Fri, 17 Feb 2023 13:55:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.38 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: stsp at users dot sourceforge.net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30127 --- Comment #14 from Stas Sergeev --- (In reply to Florian Weimer from comment #12) > > But I hope the traversal of _r_debug list > > will not became the official solution, just > > as well as using linkmap pointers directly. >=20 > Why? The handles are void *, so there isn't any type-checking today, and For example getting a handle with dlopen() can increment a refcount, making sure that handle is not freed unexpectedly. > > So maybe you don't need such an allocator, > > but of course I am not aware of a use-case > > you are referring to. >=20 > There's no lock that synchronizes the traversal of _r_debug with concurre= nt Which is why I said I hope _r_debug is not the final solution for me. :) I understand it has multiple problems, like the one you mentioned and more. > dlopen/dlclose. Introducing that is difficult. Such locks are easily > misused, and there is no precedent for exposing glibc locks in this way. If you have a proper API for traversing, it can use such a lock, or it can use more advanced techniques to present the user with the consistent list of objects that never changes during traversal, even if someone else does dlopen/dlclose in parallel. Of course if its just an _r_debug and a manual traversal, then there are much fewer options to consider. > I think we need to do a pass first with pointer-comparison because the na= mes > are not unique per namespace. OK, as you wish, will not post a patch then, although to me it looks like a bug-fix, not even an extension. But it seems, after latest "git pull" I have 32 test failures even w/o any patches of mine, so its simpler for me to not bother. :) And I always had 1 test failure before the latest "git pull" and never seen a full pass yet (w/o any patches of mine). > > Also what do you think about the aforementioned > > void *dlaudit_load_module(const char *path, int flags); > > void *dlopen_audit(const char *path, int flags, void *cookie); > > extensions? >=20 > They seem to have poor encapsulation. If more than one module uses them, = the > auditor registered in that way might see unexpected auditing events, with > unrecognizable cookies. Good point! Lets do 2 small amends then. - void *dlaudit_load_module(const char *path, int flags); As above, no change. - void *dlopen_audit(const char *path, int flags, void *audit_handle, void *cookie2); dlopen_audit() is changed: now the auditor handle is explicitly passed, so this solib will only be audited by that auditor plus all "legacy" ones (that are loaded by other means). Also "cookie2" is not passed as a cookie to la_xxx() call-backs, but instead put somewhere into the link_map struct. The designated auditor will easily access that cookie2 and "legacy" auditors do not care. This seems to remove the problems you mentioned, doesn't it? --=20 You are receiving this mail because: You are on the CC list for the bug.=