Allowing an option to redirect stdout to a file instead of explicitly suppressing it with /dev/null

[arizvisa]

Feature request description

Podman has a boolean parameter, --noout, that suppresses output. This is done by opening "/dev/null" and re-assigning it to os.Stdout.

Instead of explicitly redirecting it to "/dev/null", it would be significantly more useful to add an output parameter that allows the user to specify a file. This allows for the ability to capture anything produced by podman (such as anything produced with --format json), and if suppression is still necessary it can be done by specifying "/dev/null" explicitly.

Suggest potential solution

PR #16518 is unrelated, but appears to be the same code and seems like it could be fairly easy to convert the "noout" parameter to something like "out" and promote it to a StringFlag. Then instead of stashing a bool in PodmanConfig, it would be a string...and then finally in nooutHook, you would os.OpenFile the parameter and leave the fd dangling.

Have you considered any alternatives?

Well.. you can spawn /bin/sh as your ppid, but if you can use /bin/sh anyways, then I'm unsure of the original purpose for the --noout parameter.

Additional context

My orignal intention was to just capture the image id to a file without having to spawn a shell, similar to the --uuid-file parameter from the dead rkt container-engine project.

[giuseppe]

in what environment would you run podman that is not possible to open another file as stdout?

[arizvisa]

As mentioned, it's similar to the origins of the original parameter #11515 whom didn't need to justify it in its corresponding PR, but fair enough.. as I have one. It's strictly when using exec(3) via systemd to pass untrusted parameters to podman in order to capture an id from podman-run(1) and json from podman-images(1).

I'm taking untrusted user input and using it to generate a systemd.unit(5) by storing all variables to an EnvironmentFile and hence would like to entirely avoid any kind of shell parsing when podman gets exec'd. Of course there's the "StandardOutput" directive from systemd.exec(5) which would allow me to redirect stdout and capture podman's output to deliver back to the user, but variables set with Environment= are only usable with Exec*= directives.

Hence when I revisited podman's documentation in an attempt to figure out some "safe" hack, I saw that the functionality already existed in podman but was being redirected to /dev/null instead of a file chosen by the user...which was a kind of strange feature to discover (as it removes a capability instead of adding one). Regardless, it ended up getting implemented.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[arizvisa]

(not stale)

Seems like PR #17283 is duplicating the same pattern of --quiet redirecting stdout to null instead of enabling the invoker to decide what to do with it. This is being done for podman-machine-init(1) in order to appear symmetrical with podman-machine-start(1).

If a PR is desired, I don't mind doing it..I just don't work at RH, so I expect the contribution to get shot down since it appears that other software could already be settling on this particular parameter in order to avoid having to use the parent process themselves to redirect output.

[rhatdan]

This is a fully open source project. You do not need to work at Red Hat to have PRs accepted. The PR has to add useful functionality and not a lot of burden on the maintainers of the project though. Opening a PR makes it much more likely your change is accepted.

[arizvisa]

Took a while to get approval from all the required people. PR #18657 fixes this issue and a bug with the original "--noout" parameter.

Btw, it's pretty awesome how make localsystem just straight-up rm -rf's all the containers in your home directory (b205e04) when running the system tests as per README.md. I guess it just gives podman development a unique flavor. Heh. :)

[arizvisa]

Closing this issue as it was resolved by PR #18657. 'Twas a fun 2 months.

[rhatdan]

Thanks for sticking with it. @arizvisa