Thanks for pushing that forward!
I’m wondering if we should provide something like a snap man command as a stop gap for all releases. This might even be implemented by leveraging a snap installed on first use that runs the tools confined, perhaps? It might also fallback to the system man pages, so that it may be aliased as man itself if the user chooses to.
Maybe. I’m a bit wary of that creating confusion about which command people need to run, and being a “sticky” interface wart that has to hang around for a long time.
Alternative proposal: I could backport just the AppArmor support to older releases. That still provides pretty good coverage, even if imperfect, and I think it’s a reasonable compromise between backporting effort and actual risk given that this is proactive hardening rather than a response to something known to be full of holes.
If there’s a solid reason this definitely isn’t acceptable, then I think backporting the whole thing would be less overall effort than “snap man”. It’d require a new upstream version of libpipeline (API additions), and the man-db patch would be a few thousand lines, so I don’t particularly relish it; but there’d be many fewer moving parts and it wouldn’t expose a changed interface to users.
For Ubuntu, IMO backporting just the AppArmor profile changes would be sufficient to enable the feature in snapd. snapd is of course cross distro and feeding even the apparmor profile to other distributions would be problematic, let alone the larger patch for the seccomp changes. As such, I’m not sure what to suggest… some distros might want to take the man page feature without the man command hardening, some may not. Does it make sense to make the snapd man support (perhaps compile-time) conditional? This way Ubuntu can backport the apparmor changes to 17.10 and earlier, take the full set of changes in 18.04 and other distros can decide what to do for themselves.
The idea of having something builtin is precisely offering a fallback that will work no matter what distribution people have at hand, and whether particular patches for man/etc were applied.
Maybe. But it’s a bit of a rabbit-hole: for instance, it wouldn’t work with w3mman or vim's :Man plugin, and probably a whole bunch of other stuff along those lines too; completion would need work (and to be fast); there’s no particularly clear way to integrate it with apropos (bearing in mind that when you’re searching for an installed man page system-wide you really don’t care how it got onto the system); and so on.
Plus of course people can always do man -l /snap/man/... anyway, and users who are more familiar with man than with snaps will probably do that before finding snap man. So IMO, if there’s actually a credible concern about confinement escapes via man (taken as a given for this whole thread, I suppose), then there’s no way around hardening man anyway.
I’m concerned about creeping interface cruft that will end up being spread around in not-particularly-snap-related code that I have to help maintain, and hang around for years after my hardening patches are present everywhere, when maybe a bit more effort now could avoid that. That’s why I’m trying to feel out acceptable parameters more generally, rather than the single possibility of a builtin command.
Personally I think that, as there is a trivial but essential integration step a distribution needs to do for man to find the snap manpages, and as mandb’s security track record is rather good, and there’s a reasonably easy way of a user looking at a manpage if the integration step has not been taken, there isn’t a need to add anything further to snapd beyond the work needed to expose the manpages in a single location.
Concretely, and as a strawman, snapd can start exposing manpages in /var/lib/snapd/man/. In Ubuntu and other places that carry the patch (or that consider it unnecessary), /etc/manpath.config would be updated to search there; in a distro that doesn’t do the integration work, a user can
/var/lib/snapd/man to $MANPATH in their ~/.profile, orMANDATORY_MANPATH /var/lib/snapd/man/ to their ~/.manpath — this one might be simpler to communicate.-l.For people that are looking for manpages, are using snaps, and are using a distro that hasn’t done the integration work, telling them “drop this .manpath in your home” seems fine to me.
Remember this extra hardening is upstream, so other distros will get it eventually (although I assume it’s compile-time optional), and mandb’s security record is such that even without it we’re probably ok.
To put it another way: distros that aren’t going to be picking up the hardening work are probably devmode already…
While I’m not sure I agree with the statement that distros not picking up the hardening work are probably devmode (Mint and its derivatives come to mind), I do agree that man has had a reasonable security track record. We should be doing what we can when passing uncontrolled input from snaps to unconfined programs. Sometimes we do that through interfaces (eg, dbus services) and sometimes we harden the system (eg, bash completion). Colin has done great work here (thank you!) and IMO is doing it the right way-- the code went upstream and everyone will eventually benefit.
John’s proposal seems like a nice compromise. With his idea, snapd is not overly complicated with compile time options or extra commands; it just puts the man pages from the snaps somewhere outside of MANPATH. If a distro chooses to integrate sooner via packaging, the distro is free to pickup the man hardening sooner too. If the distro doesn’t, snapd honors that choice by not updating MANPATH itself and a sysadmin can choose to set the manpath globally or a user can choose to do so locally for herself.
In thinking about this more I think it is also worth noting that irrespective of snapd, man is currently processing untrusted user input during tons of package builds (I suspect the man code has been analyzed for vulnerabilities quite a lot over the years as a result) and that’s why exploitable parsing bugs/etc are treated as CVEs with priority by all the distros. snaps extend the reach of those vulnerabilities of course, but John’s proposal honors distro and user choice until everyone can benefit from Colin’s great work.
If there is agreement that the processing of the man pages is secure enough, doing something simpler definitely sounds good. That said, we still need a polished interface that tends to work, probably via snap man, because we want to expose a way that tends to work without people having to guess what a particular user has done to their own environment.
Without that, consider that every single time a third-party has to say “read the man page”, they have to attach instructions… and everytime someone reports “the man page doesn’t work”, they have to ask whether the user has done X, Y or Z2, to make sure that man pages work at all. That’s not how a polished user experience should feel like.
Another alternative is to just go ahead and integrate with the real man so that it indeed just works without special flags.
Is there any update on this feature?
I’m the snap maintainer of two command line tools (tio and lxi-tools) both of which could really use support for man pages.
Is there any action here yet? if I have some manual installed from snap, for example
/var/lib/snapd/snap/taskwarrior-plars/2/share/man
I can read it by doing:
export MANPATH=/var/lib/snapd/snap/taskwarrior-plars/2/share/man:$MANPATH
man task
Can snapd manage that for me?
Integration of manpages would really be useful.
One of the advantages of snap wrt other technologies is that cli applications feel seamlessly integrated in the environment (e.g. you can launch them from the command line without wrappers, etc.), and manpages are one of the few items where this integration is broken.
CLI stuff with limited --help output becomes really hard to use without access to its manpages.
Well if I understood the bug report correct, some sort of manpage support should be available once either core20 becomes available for multipass (multipass list should have core20 listed) or the fix is backported.
Unfortunately that comment is just about the manpage side of things, there is still work that we need to do on the snapd side, (which was started somewhat) however we haven’t finished that yet as other things have come up. So even if the manpages debian package fix was backported, it still wouldn’t work because we haven’t done the work in snapd yet.
So once the work in snapd is completed, will there be a new setting in snapcraft.yaml to take care of manpages? Something like:
parts:
snap:
manpage-source: gitlab.com/snap/manpages
to automatically include and link all manpages in the manpage-source.
It’s not clear what the exact syntax would look like, but yes there will be some way to specify in the snapcraft.yaml what manpages should be installed on the system when the snap is installed (and implemented in such a way that removing the snap removes those manpages).
Thanks a lot! That covers everything I want to do. I just want to be able to type (for example) man grep. The difficult part is probably to design for zfs and git style when manpages are broken up in subcommands.
Has there been any progress on this?
@jdstrand, no unfortunately not. The latest is some info from folks here: https://bugs.launchpad.net/snapd/+bug/1575593, and a PR opened by @chipaca here: https://github.com/snapcore/snapd/pull/8079. At some point we may try to pick that up, but folks are certainly welcome to build on that PR and try to push it through. I think that @zyga also landed some changes a bit ago which makes this easier (by providing a feature through which snapd can more easily export files from a snap to the host’s OS)
Reviving this thread as I have a need for shipping man-pages with microovn.
The microovn snap is built from among other things the Open vSwitch (OVS) and Open Virtual Network (OVN) projects.
These projects provide detailed reference documentation as system manual pages distributed with the project.
I have heard from a colleague in the HPC team that they would also be interested in man-pages cc @nuccitheboss.
For fun I made an attempt at shipping the requirements with the snap, but I fear the people who want to read those pages will have a hard time finding the command regardless of how well it is documented.
Other things I’m contemplating is to request permission to write to /etc/manpath.config through the system-files interface or ~/.manpath through the personal-files interface but that also does not feel great.
It feels very much like infrastructure that snapd and snapcraft ought to provide?