Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot

[Filipe Brandenburger]

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.

Cheers,
Filipe

smime.p7s
Description: S/MIME Cryptographic Signature