597ebeb60f
This ended up more complicated then expected. Lets start first with the problem to show why I am doing this: Currently we simply execute ps(1) in the container. This has some drawbacks. First, obviously you need to have ps(1) in the container image. That is no always the case especially in small images. Second, even if you do it will often be only busybox's ps which supports far less options. Now we also have psgo which is used by default but that only supports a small subset of ps(1) options. Implementing all options there is way to much work. Docker on the other hand executes ps(1) directly on the host and tries to filter pids with `-q` an option which is not supported by busybox's ps and conflicts with other ps(1) arguments. That means they fall back to full ps(1) on the host and then filter based on the pid in the output. This is kinda ugly and fails short because users can modify the ps output and it may not even include the pid in the output which causes an error. So every solution has a different drawback, but what if we can combine them somehow?! This commit tries exactly that. We use ps(1) from the host and execute that in the container's pid namespace. There are some security concerns that must be addressed: - mount the executable paths for ps and podman itself readonly to prevent the container from overwriting it via /proc/self/exe. - set NO_NEW_PRIVS, SET_DUMPABLE and PDEATHSIG - close all non std fds to prevent leaking files in that the caller had open - unset all environment variables to not leak any into the contianer Technically this could be a breaking change if somebody does not have ps on the host and only in the container but I find that very unlikely, we still have the exec in container fallback. Because this can be insecure when the contianer has CAP_SYS_PTRACE we still only use the podman exec version in that case. This updates the docs accordingly, note that podman pod top never falls back to executing ps in the container as this makes no sense with multiple containers so I fixed the docs there as well. Fixes #19001 Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2215572 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Podman Documentation
The online man pages and other documents regarding Podman can be found at Read The Docs. The man pages can be found under the Commands link on that page.
Build the Docs
Directory Structure
| Directory | |
|---|---|
| Markdown source for man pages | docs/source/markdown/ |
| man pages aliases as .so files | docs/source/markdown/links/ |
| target for output | docs/build |
| man pages | docs/build/man |
| remote linux man pages | docs/build/remote/linux |
| remote darwin man pages | docs/build/remote/darwin |
| remote windows html pages | docs/build/remote/windows |
Support files
| docs/remote-docs.sh | Read the docs/source/markdown files and format for each platform |
| docs/links-to-html.lua | pandoc filter to do aliases for html files |
| docs/use-pagetitle.lua | pandoc filter to set html document title |
Manpage Syntax
The syntax for the formatting of all man pages can be found here.
API Reference
The latest online documentation is
automatically generated by two cooperating automation systems based on committed upstream
source code. Firstly, the Cirrus-CI docs task builds
pkg/api/swagger.yaml and uploads it to a public-facing location (Google Storage Bucket -
an online service for storing unstructured data). Second, Read The Docs
reacts to the github.com repository change, building the content for the libpod documentation
site. This site includes for the API section,
some javascript which consumes the uploaded swagger.yaml file directly from the Google
Storage Bucket.
Since there are multiple systems and local cache is involved, it's possible that updates to documentation (especially the swagger/API docs) will lag by 10-or-so minutes. However, because the client (i.e. your web browser) is fetching content from multiple locations that do not share a common domain, accessing the API section may show a stack-trace similar to the following:
If reloading the page, or clearing your local cache does not fix the problem, it is
likely caused by broken metadata needed to protect clients from cross-site-scripting
style attacks. Please notify a maintainer
so they may investigate how/why the swagger.yaml file's CORS-metadata is
incorrect, or the file isn't accessible for some other reason.
Local Testing
To build standard man pages, run make docs. Results will be in docs/build/man.
To build HTMLized man pages: Assuming that you have the dependencies installed, then also install (showing Fedora in the example):
$ sudo dnf install python3-sphinx python3-recommonmark
$ pip install sphinx-markdown-tables myst_parser
(The above dependencies are current as of 2022-09-15. If you experience problems, please see requirements.txt in this directory, it will almost certainly be more up-to-date than this README.)
After that completes, cd to the docs directory in your Podman sandbox and then do make html.
You can then preview the html files in docs/build/html with:
python -m http.server 8000 --directory build/html
...and point your web browser at http://localhost:8000/