Hello!
Personally, don't we have philosophical contradiction here? -- Journal
is positioned as syslog alternative with more wide functionality, but in
current case we offer to turn off whole journal to make functionality
only as transport. No problem, but is RFE to incorporate
ExcludeMetaData= parameter to /journald.conf acceptable here?
Syntax: ExcludeMetaData=[meta[=keyword1,keyword2,...keywordN]]
For current usecase: ExcludeMetaData=_CMDLINE. Or, to make it more
flexible: ExcludeMetaData=_CMDLINE=[keyword1],[keyword2],...[keywordN].
E.g.:
=======
ExcludeMetaData=_CMDLINE=pass,password
ExcludeMetaData=_UID=1000,k_mikhail
=======
to exclude defined parameters. Or:
=======
ExcludeMetaData=_CMDLINE
ExcludeMetaData=_UID
=======
to exclude common (whole) metadata.
Acceptable?
18.08.2016 14:25, Lennart Poettering пишет:
On Wed, 17.08.16 12:10, Divya Thaluru (divya.thal...@gmail.com) wrote:
Hi,
Journalctl stores metadata like "_UID,_GID,_CMDLINE,_SYSTEMD_CGROUP etc…"
for each message. Is there any way, can we encrypt metadata (commandline
info) so sensitive information wont be stored.
If encryption of metadata is not possible, can we disable collecting the
metadata?
The journal does not support encryption, and it does not disable
collecting metadata implicitly. You may however turn off all storage
by the journal by setting Storage=none in journald.conf. In that mode
you may optionally connect another syslog daemon to it via
ForwardToSyslog=yes, which implements the features you are looking for.
Lennart
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
