Ticket #577 (closed task: fixed)

Opened 5 years ago

Last modified 5 years ago

FHS exception for Heimdal

Reported by: ktdreyer Owned by:
Priority: minor Keywords: meeting
Cc: ktdreyer, orion Blocked By:


Proposal topic

FESCo provides a FHS exception for Heimdal, an alternative Kerberos implementation. Review request is at https://bugzilla.redhat.com/613001


Heimdal provides an alternative Kerberos implementation to MIT Kerberos, the default in Fedora. I'm probably doing an injustice here, but my poor-man's summary of the differences between the two is that MIT's implementation is stable while Heimdal contains more features.

Beyond the new features etc, one reason for including Heimdal in Fedora is that Samba4 is currently bundling a Heimdal fork. The Samba team has been working with the Heimdal community and abartlet indicates that Samba could probably use this package instead of bundling.

Problem space

MIT's Kerberos binaries, manpages, and development files share identical names to MIT.

The binaries themselves have differing command-line options. The library APIs are different. The client-to-server wire protocol is the same (RFC 4120), but the administrative tool (kadmin) is incompatible between a MIT client and Heimdal server.

The three solutions we've identified are

  1. Install to /usr/heimdal. This will require an exception from FESCo.
  1. Rename the Heimdal files to not conflict with MIT. Eg.

"/usr/bin/kinit.heimdal", "kadmin.heimdal", etc. Use alternatives to switch between the two Kerberos implementations.

  1. Use Conflicts: with the appropriate MIT packages. You have to choose to

install one or the other.

With this FESCo ticket, I'm asking for #1.

Solution Overview

This proposal is that FESCo grant Heimdal an FHS exception to install into a directory such as /usr/heimdal.

Active Ingredients

The "krb5-workstation" package in Fedora is the MIT implementation. The review bug for Heimdal is https://bugzilla.redhat.com/613001 . The review bug contains background, a list of conflicting files in Heimdal, and some discussion on the pros and cons of using alternatives or Conflicts: to remedy this.



Change History

comment:1 Changed 5 years ago by ktdreyer

  • Cc ktdreyer added
  • Keywords meeting added

comment:2 follow-up: ↓ 3 Changed 5 years ago by toshio

Why not %{_libdir}/heimdal? That portion at least shouldn't require an FHS exception.

comment:3 in reply to: ↑ 2 Changed 5 years ago by spot

FWIW, I do not recommend that FESCO grant this FHS exception. It sets a poor precedent, there are better ways to handle the libraries (as Toshio points out above), and we have documented methods (alternatives) to handle the binaries.

comment:4 Changed 5 years ago by ktdreyer

My preference is to avoid breaking FHS where possible, and we may be able to make alternatives work in conjunction with what Toshio suggests.

I wanted to mention that this is'nt an entirely "out of the blue" request; In EL5, several parts of MIT is in /usr/kerberos. This has changed somewhat in recent Fedoras, but Rawhide's krb5-appl-clients and krb5-appl-servers still contain several binaries and man pages such as /usr/kerberos/bin/ftp, /usr/kerberos/bin/telnet, etc.

Like most of the folks that have spoken on the Review bug already, I don't strongly care either way. I would just like to have an on-record decision.

comment:5 Changed 5 years ago by mmaslano

-1 to exception

comment:6 Changed 5 years ago by orion

FYI - krb5-app{-clients,-servers} still uses /usr/kerberos/{bin,sbin,man} for the kerberized ftp, r*, and telnet commands and servers. Has FESCO addressed this? Would /usr/heimdal be acceptable for these commands?

comment:7 Changed 5 years ago by kevin

  • Resolution set to fixed
  • Status changed from new to closed

This exception was not approved at this time.

I think we would like to see a combo of 2 and 3 methods... ie, alternatives where possible and conflicting devel files perhaps.

comment:8 follow-up: ↓ 10 Changed 5 years ago by orion

  • Resolution fixed deleted
  • Status changed from closed to reopened

I would like to see clarification with regards to the krb5-appl-* utilities (see previous comment) using /usr/kerberos and if /usr/heimdal would be okay for the heimdal equivalents of those.

Merge review for krb5-appl is here: https://bugzilla.redhat.com/show_bug.cgi?id=570951. No fuss over using /usr/kerberos was made then.

comment:9 Changed 5 years ago by orion

  • Cc orion added

comment:10 in reply to: ↑ 8 Changed 5 years ago by nalin

Replying to orion:

I would like to see clarification with regards to the krb5-appl-* utilities (see previous comment) using /usr/kerberos and if /usr/heimdal would be okay for the heimdal equivalents of those.

The rsh client in /usr/kerberos/bin speaks a Kerberos-specific variation on the protocol, but if it fails to authenticate using Kerberos to a specific host, it execs the normal rsh client to retry using the traditional protocol.

The version from krb5-appl-clients does not implement the traditional protocol, so this lets it avoid any need to be setuid root. The Heimdal rsh client functions similarly: by design, both stand in for but fall back to calling /usr/bin/rsh. This means it needs to have a pathname other than /usr/bin/rsh for it to work at all.

Renaming the binary is more out of line with upstream than moving it, so FWIW I would also prefer an exception be made here.

comment:11 Changed 5 years ago by toshio

My POV is that /usr/kerberos also has no justification.

To continue using the current strategy explained by nalin, /usr/kerberos/bin/rsh would belong in something like /usr/libexec/{kerberos,krb5,mit-kerberos}/rsh .. Files that would need to be multilib would belong under %{_libdir}/{kerberos,krb5,mit-kerberos}/

I'm not commenting on whether that strategy is preferable to renaming in this ticket as I don't know enough about that aspect of the problem at this time.

comment:12 Changed 5 years ago by orion

Why libexec? There are utilities meant to be in a user's path.

comment:13 Changed 5 years ago by toshio

According to nalin's comment they aren't.

comment:14 Changed 5 years ago by orion

No, the user executes /usr/kerberos/bin/rsh (or whatever) and then if the kerberos auth fails it falls back to executing /usr/bin/rsh. So /usr/kerberos/bin/rsh absolutely needs to be in the path and krb5-appl-clients installs a file in /etc/profile.d to do this.

comment:15 Changed 5 years ago by toshio

So why are you complaining about /usr/libexec/krb5?

Neither /usr/kerberos/bin nor /usr/libexec/krb5 are in the default PATH. So when you install the kerberized utilities, you either have to setup a special case to add those or you don't. There's no difference other than which directory you'd be adding to the PATH.

Ah actually I see what you mean. You aren't complaining about having to setup the PATH; you're complaining about the definition of libexec. So I think that %{_libdir}/{krb5,kerberos,mit-kerberos} would be the appropriate place. I was remembering that we'd talked about libexec being the proper place for programs as opposed to libraries before... but it's really the proper place for programs-invoked-by-other-programs which makes it not appropriate here. Although, the whole architecture that we're talking about might be better served with an /usr/bin/rsh that's a wrapper that attempts to invoke one of the other contenders for that name (which could then live in /usr/libexec). But that's a different conversation.

comment:16 Changed 5 years ago by orion

No place is correct according to the FHS:

/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts.

/usr/libexec isn't even mentioned, but yeah it is supposed to be same as above.

Large software packages must not use a direct subdirectory under the /usr hierarchy.

There is some precedent for /usr/lib. That is where openmpi/mpich2 are installing their binaries.

comment:17 Changed 5 years ago by toshio

Right. That's why I mentioned the wrapper -- then the programs become helper programs for the wrapper. Which is what our usage of libexec is for (from the GNU coding standards). Barring that, our precedent is to use %{_libdir} which follows Debian.

comment:18 Changed 5 years ago by kevin

FESCo doesn't want to grant an exception for /usr/heimdal/ at this point. Please see if you can use one of the other solutions? /usr/lib? /usr/libexec?

comment:19 Changed 5 years ago by orion

  • Resolution set to fixed
  • Status changed from reopened to closed

I guess we'll try /usr/lib/heimdal/bin.

Note: See TracTickets for help on using tickets.