[Pkg-freeradius-maintainers] Bug#911180: Bug#911180: freeradius: freeradius refuses to start - missing libs

Michael Stapelberg stapelberg at debian.org
Tue Nov 6 15:47:48 GMT 2018


Thanks for the reminder. It’s hard to keep track of everything that’s going
on.

The lintian tag description states:

> The only time a binary or shared library in a Debian package should set
RPATH or RUNPATH is if it is linked to private shared libraries in the same
package. In that case, place those private shared libraries in
/usr/lib/package. Libraries used by binaries in other packages should be
placed in /lib or /usr/lib as appropriate, with a proper SONAME, in which
case RPATH/RUNPATH is unnecessary.

It seems like this is exactly what’s happening here?

Can we try removing the rpath from where it can be removed, and overriding
the lintian tag for the legitimate cases?

I’d prefer to not open libraries to the public unless coordinated with
upstream, as they need to be aware of the stability guarantees (e.g. when
to bump the SONAME).

Thanks!

On Tue, Nov 6, 2018 at 4:27 PM Dimitri John Ledkov <xnox at ubuntu.com> wrote:

> Hey,
>
> On Mon, 5 Nov 2018 at 21:07, Michael Stapelberg <stapelberg at debian.org>
> wrote:
> >
> > I still don’t quite understand why you stripped the rpaths to begin
> with. Can you explain? I think that’d be good to understand before making a
> decision :)
> >
>
> Please recall that when you last tried to upload freeradius it got
> autorejected by ftp masters due to rpath.... email from 2nd of June
> from you to me....
>
> """
> freeradius-postgresql: lintian output: 'binary-or-shlib-defines-rpath
> usr/lib/freeradius/rlm_sql_postgresql.so /usr/lib/x86_64-linux-gnu',
> automatically rejected package.
> freeradius-postgresql: If you have a good reason, you may override
> this lintian tag.
> freeradius-iodbc: lintian output: 'binary-or-shlib-defines-rpath
> usr/lib/freeradius/rlm_sql_iodbc.so /usr/lib', automatically rejected
> package.
> freeradius-iodbc: If you have a good reason, you may override this lintian
> tag.
> freeradius-python2: lintian output: 'binary-or-shlib-defines-rpath
> usr/lib/freeradius/rlm_python.so /usr/lib/python2.7/config',
> automatically rejected package.
> freeradius-python2: If you have a good reason, you may override this
> lintian tag.
> """
>
> And spot checking this revealed that rpath is redundant for most of
> the modules shipped - hence i stripped rpath from them all.
> However, clearly that was false for all of them as some of them do use
> private lib as now analyzed.
>
> My preference is to not have rpath set on any of these, and simply
> expose libfreeradius-dhcp.so and libfreeradius-eap.so as public
> libraries.
>
> Also i'm pondering how come freeradius does not set ldpath when trying
> to dlopen the plugins from the plugin dir.... cause that would also
> work without rpath set on every plugin.
>
> Regards,
>
> Dimitri.
>
>
>
> > On Mon, Nov 5, 2018 at 9:06 PM Dimitri John Ledkov <xnox at ubuntu.com>
> wrote:
> >>
> >> Hello,
> >>
> >> On Mon, 5 Nov 2018 at 18:19, Michael Stapelberg <stapelberg at debian.org>
> wrote:
> >> >
> >> > Sorry, didn’t see the merge request. I fixed my notification
> settings, merged the MR, and gave you permission to the repository.
> >> >
> >>
> >> No worries. I myself only starting to figure out how to correctly use
> >> salsa. It is quite new in how everything works.
> >>
> >> So about the bug, here is the full scope of affected files:
> >>
> >> /usr/lib/freeradius# readelf -d *.so | grep -e '\[libfreeradius' -e
> File:
> >> File: libfreeradius-dhcp.so
> >> File: libfreeradius-eap.so
> >> File: libfreeradius-radius.so
> >> File: libfreeradius-server.so
> >> File: proto_dhcp.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-dhcp.so]
> >> File: proto_vmps.so
> >> File: rlm_always.so
> >> File: rlm_attr_filter.so
> >> File: rlm_cache.so
> >> File: rlm_cache_memcached.so
> >> File: rlm_cache_rbtree.so
> >> File: rlm_chap.so
> >> File: rlm_counter.so
> >> File: rlm_cram.so
> >> File: rlm_date.so
> >> File: rlm_detail.so
> >> File: rlm_dhcp.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-dhcp.so]
> >> File: rlm_digest.so
> >> File: rlm_dynamic_clients.so
> >> File: rlm_eap.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_fast.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_gtc.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_leap.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_md5.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_mschapv2.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_peap.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_pwd.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_sim.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_tls.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_eap_ttls.so
> >>  0x0000000000000001 (NEEDED)             Shared library:
> [libfreeradius-eap.so]
> >> File: rlm_exec.so
> >> File: rlm_expiration.so
> >> File: rlm_expr.so
> >> File: rlm_files.so
> >> File: rlm_ippool.so
> >> File: rlm_krb5.so
> >> File: rlm_ldap.so
> >> File: rlm_linelog.so
> >> File: rlm_logintime.so
> >> File: rlm_mschap.so
> >> File: rlm_otp.so
> >> File: rlm_pam.so
> >> File: rlm_pap.so
> >> File: rlm_passwd.so
> >> File: rlm_perl.so
> >> File: rlm_preprocess.so
> >> File: rlm_python.so
> >> File: rlm_radutmp.so
> >> File: rlm_realm.so
> >> File: rlm_redis.so
> >> File: rlm_rediswho.so
> >> File: rlm_replicate.so
> >> File: rlm_rest.so
> >> File: rlm_soh.so
> >> File: rlm_sometimes.so
> >> File: rlm_sql.so
> >> File: rlm_sql_freetds.so
> >> File: rlm_sql_iodbc.so
> >> File: rlm_sql_mysql.so
> >> File: rlm_sql_null.so
> >> File: rlm_sql_postgresql.so
> >> File: rlm_sql_sqlite.so
> >> File: rlm_sqlcounter.so
> >> File: rlm_sqlippool.so
> >> File: rlm_test.so
> >> File: rlm_unix.so
> >> File: rlm_unpack.so
> >> File: rlm_utf8.so
> >> File: rlm_wimax.so
> >> File: rlm_yubikey.so
> >>
> >> The majority of files indeed are fine. But a few that use
> >> libfreeradius-dhcp.so and libfreeradius-eap.so are not. I have two
> >> options to fix this:
> >>
> >> (1) do not strip rpath from files that use libfreeradius-eap|dhcp.so
> >>
> >> or
> >>
> >> (2) make these two libraries public by creating symlinks
> >> /usr/lib/libfreeradius-eap|dhcp.so ->
> >> freeradius/libfreeradius-eap|dhcp.so
> >>
> >> because in practice they are public system soname-less libraries
> >> shipped in libfreeradius3 and one can compile against them using
> >> libfreeradius-dev.
> >>
> >> In other packages, I went ahead and added sonames to such libraries
> >> and made them public - even if soname .0 and strict << versioning.
> >>
> >> I can implement either of the above two options, what do you prefer?
> >>
> >> > Thanks for looking into this!
> >> >
> >> > On Mon, Nov 5, 2018 at 6:53 PM Dimitri John Ledkov <xnox at ubuntu.com>
> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> On Tue, 16 Oct 2018 at 21:48, Michael Stapelberg <
> stapelberg at debian.org> wrote:
> >> >> >
> >> >> > Dimitri, this is a result of your change
> https://salsa.debian.org/freeradius-team/freeradius/commit/1fad1d069a8148c5c640157147f4ad1b111ca919.
> Could you revert it for the time being, and, if you chose to go forward
> with a fix, outline the rationale? The commit only describes the what, not
> the why. Specifically, in which way was the rpath “bogus”?
> >> >> >
> >> >>
> >> >> Digging more into this, to understand how to fix this right.
> >> >>
> >> >> > Also, while at it, could you please ensure that
> https://salsa.debian.org/freeradius-team/freeradius is in sync with
> what’s in the archive? Your NMU is not reflected in the changelog, for
> example :-/
> >> >> >
> >> >>
> >> >> I can't actually do this. "Ready to be merged automatically. Ask
> >> >> someone with write access to this repository to merge this request"
> >> >> that's why when I uploaded NMU I opened the merge request on 25th of
> >> >> September at
> https://salsa.debian.org/freeradius-team/freeradius/merge_requests/2
> >> >>  please merge that, I think you are the only one who has the rights
> to
> >> >> the repository.
> >> >>
> >> >>
> >> >> --
> >> >> Regards,
> >> >>
> >> >> Dimitri.
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> > Michael
> >>
> >>
> >>
> >> --
> >> Regards,
> >>
> >> Dimitri.
> >
> >
> >
> > --
> > Best regards,
> > Michael
>
>
>
> --
> Regards,
>
> Dimitri.
>


-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-freeradius-maintainers/attachments/20181106/13493467/attachment-0001.html>


More information about the Pkg-freeradius-maintainers mailing list