Snappy installed manpages aren't accessible through man
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| snapd |
Low
|
Unassigned |
Bug Description
Once installed a snap package in ubuntu core, it's not possible to access to its man pages without manually loading it from the /snap/<
I guess the same that is done for /bin/ should be done for the man and info pages, and then MANPATH (or /etc/manpath.
Magosányi Árpád (mag-magwas) wrote : | #2 |
I guess this is an instantiation of a greater architectural challenge:
Snap is meant to separate applications together with their respective dependency chains, but is augmenting a platform where there is a strong tradition of inter-package integration through the filesystem namespace. You will reach manpages, fonts, language specific packages, etc. through well-defined paths in the filesystem. This is (I guess) solved for the dependencies for the snapped application, but how do you/can you provide those filesystem-based services from a snap?
Are there any discussion of this greater issue somewhere?
summary: |
- Snappy installed manpages aren't inaccessible through man + Snappy installed manpages aren't accessible through man |
Christian Ehrhardt (paelzer) wrote : | #3 |
Yeah, I'd totally like that feature as well.
As an outline of one potential solution:
- the path "inside" the snap is the usual man page paths, but relative in there.
- if man would just know that the binaries /snap/bin/
- using the function of MANPATH_MAP of /etc/manpath.config could do that (maybe via a /etc/manpath.
But just "as is" this would break confinement - so we very would need a proper interface designed for that.
In general this might only be reasonable for classic, there snapd could provide such a wrapper.
Just wanted to document the thoughts so far - thanks to #snappy channel for some discussion already.
Surely has to be discussed by people with more insight into the snap environment, but it would be a really nice feature to have in classic environments.
Colin Watson (cjwatson) wrote : | #4 |
You don't need to set MANPATH here, and almost certainly shouldn't. man automatically infers manpath elements from PATH: for PREFIX/bin, it automatically tries PREFIX/man, PREFIX/bin/man, PREFIX/share/man, and PREFIX/
Colin Watson (cjwatson) wrote : | #5 |
(Previous comment is with my man-db maintainer hat on, by the way.)
Christian Ehrhardt (paelzer) wrote : | #6 |
Thanks a lot Colin for that extra insight, that might make the resolution of this issue much easier.
And while placing the manpages in those directories they could be prefixed with the snap prefix of multi-app snaps.
So if you snapp has:
foobar.foo
foobar.bar
But the native build systen only build foo.1 and bar.1 - on all the mapping and file organization we do to make a snap available one could also map those to foobar.foo.1 and foobar.bar.1 in the directories suggested by Colin.
I'll try to give this a shot when I look at my snap again anyway next time.
Need to check if that works as is, or needs some extra snapcraft bits to get the stuff placed this way.
Changed in snappy: | |
status: | New → Triaged |
importance: | Undecided → Low |
no longer affects: | ubuntu-snappy (Ubuntu) |
affects: | snappy → snapd |
Adam Conrad (adconrad) wrote : | #7 |
This could use some attention. With talks of migrating some debs to snaps, it's come up again that snaps don't have manpages, which is a regression.
Colin Watson (cjwatson) wrote : | #8 |
I've uploaded man-db 2.8.1-1 to Debian, and that will shortly be synced into bionic; this uses a combination of strategies involving seccomp and AppArmor to confine the processes that parse manual pages.
How much do we care about backporting some or all of this to earlier series before allowing snaps to make manual pages available? Considerations here:
* The AppArmor support is probably relatively easy to backport. It isn't upstream as yet, since AppArmor profiles tend to have a lot of hardcoded distribution-
* The seccomp support is upstream (technically as of 2.8.0, but 2.8.1 fixes several serious problems). It uses a pretty restrictive filter for most things, basically just allowing processes to operate on themselves and to do the sorts of things you find in data-transforming pipes, and a slightly more permissive filter that allows limited file creation for the various groff processes that need the ability to create temporary files. It would be very invasive and difficult to try to backport this.
* This is all proactive hardening: I don't think there's been an actual reported vulnerability in any of the relevant code for 15 years or more. Of course it's possible that that might change if it were a way out of snap confinement rather than an interesting curiosity.
Tyler Johnson (tejohnso) wrote : | #9 |
I followed Colin's advice above:
"So whatever bit of snap puts /snap/bin/foo in place should simply also put /snap/man/
I set up my snapcraft yaml to prime:
bin/mysnap
man/man1/mysnap.1
This resulted in the following on the filesystem after installing mysnap:
/snap/
bin/
mysnap
mysnap/current/
bin/
mysnap
man/
man1/
mysnap.1
I don't think that through snapcraft we have the ability to push something out directly to /snap/man/ so is it possible that the snap install could copy whatever is in current/man/man1 out to /snap/man/man1/ as part of the install process? Or perhaps man is being changed instead so that it will look into /snap/[
experimancer (experimancer) wrote : | #10 |
Also, a related discussion is where snap-installed apps place their configurations and how should they be accessed and integrated to host system.
An example of this is a 'youtube-dl' snap (and standard app) whose config as per its man page should be in /etc and ~/.config: "
CONFIGURATION
You can configure youtube-dl by placing default arguments (such as --extract-audio --no-mtime to always extract the audio and not copy the mtime) into
but as I have it as Snapped app they aren't there but somewhere inside Snap-directory structure.
In this regard, I think that Snap-system is not architechturally mature enough to be ueds alongisde host system apps, cause their 'isolation' thingy breaks their normal usage patterns and configurations - and the man pages.
Colin Watson (cjwatson) wrote : | #11 |
I discussed this with John Lenton and Zygmunt Krynicki a few weeks ago. My notes say that we agreed:
* ship manual pages under /snap/man in the normal way
* deduplicate pages by name (i.e. prefixing "<snap-name>.") in the same way as is done for binaries; this means that if you have a binary called <snap-name>
* add /snap/man → /var/cache/man/snap mapping for index database caches to man-db, so that snap-installed manual pages can be indexed for use by apropos/whatis
I released man-db 2.9.1 today implementing the last of these and also uploaded it to Debian unstable, so it should be in Ubuntu 20.04. Backporting the relevant one-line change (https:/
I believe others are taking care of the snapd side of things; I haven't been keeping track of that.
Status changed to 'Confirmed' because the bug affects multiple users.