#577 FHS exception for Heimdal
Closed None Opened 13 years ago by ktdreyer.

= Proposal topic =

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

= Overview =

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.

  2. 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.

  3. 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.

= Owners =

ktdreyer


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

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.

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.

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?

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.

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.

Replying to [comment:8 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.

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.

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

According to nalin's comment they aren't.

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.

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.

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.

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.

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?

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

Login to comment on this ticket.

Metadata