[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot
From: |
Andreas Grünbacher |
Subject: |
Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot |
Date: |
Wed, 15 Aug 2018 21:50:14 +0200 |
Am Mi., 15. Aug. 2018 um 18:36 Uhr schrieb Filipe Brandenburger
<address@hidden>:
>
> On Tue, Aug 14, 2018 at 11:00 AM Dmitry V. Levin <address@hidden> wrote:
> > On Mon, Aug 13, 2018 at 10:12:57PM -0700, Filipe Brandenburger wrote:
> > > See here for more details:
> > > https://github.com/dex4er/fakechroot/issues/57
> >
> > I suppose fakechroot has to be fixed to remain useful.
>
> I'm proposing using explicit symbol versions (dlvsym) in fakechroot to fix
> this:
> https://github.com/dex4er/fakechroot/pull/58
>
> > > Any chance you'd consider going back to an implementation directly
> > > using SYSCALL(...) in libattr?
> >
> > I believe commit v2.4.48~17 was the right change in this respect.
> > Note that software has been using glibc functions to access acl syscalls
> > for quite a long time, so changing libacl won't help fakechroot to handle
> > that software.
>
> I somewhat agree, but the way v2.4.48~11 reintroduces them is not
> ideal, since it interacts with LD_PRELOAD and dlsym() in unexpected
> ways. (Again, I'm not saying libattr is at fault here, just that
> LD_PRELOAD and dlsym is a somewhat incomplete API and leads to this
> kind of issues.)
>
> In a perfect world (or, at least, slightly better than this own),
> instead of libattr exporting wrappers (like libattr_lsetxattr) which
> call the glibc function (lsetxattr), I think it would be good if they
> could import the glibc symbol (address@hidden) and re-export that
> (as address@hidden, non-default symbol.)
>
> I don't really know if it's even possible to do this with linker
> scripts or, if it is, how to do that... But I think that would be an
> improvement.
Hmm, commit efa0b1ea (v2.4.48~11) was not such a good idea.
I wonder if there's a way to leave older versions of a symbol around
in a library, but to un-export it in the default version so that
programs newly built against the library will skip it. I couldn't
figure out a way to do that though.
Alternatively, we could add a second libattr with a new major version.
Andreas
- [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot, Filipe Brandenburger, 2018/08/14
- Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot, Dmitry V. Levin, 2018/08/14
- Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot, Filipe Brandenburger, 2018/08/14
- Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot,
Andreas Grünbacher <=
- Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot, Dmitry V. Levin, 2018/08/15
- Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot, Andreas Grünbacher, 2018/08/15
- Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot, Dmitry V. Levin, 2018/08/15
- Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot, Filipe Brandenburger, 2018/08/15
- Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot, Andreas Grünbacher, 2018/08/16
- Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot, Andreas Grünbacher, 2018/08/17
- Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot, Filipe Brandenburger, 2018/08/31