Hide the contents of clipboard from the systemd service logs

[nekorug]

If the user uses the provided clipmenud.service unit, the systemd logs will contain a permanent list of all the previous contents of the clipboards. This is because the content is printed to standard out every time something new is copied and systemd logs standard out for services.

I implemented an option to clipmenud that disables printing the actual contents from the clipboard to standard out. I also added the environment variable to the systemd service unit file, to make sure it is active. Please give me feedback on anything you want to change, such as if this "privacy mode" should be default on or off. I left it on by default, but it's of course possible to have it off by default and have the systemd unit start with it either way.

[cdown]

Hey there!

I'm not super convinced that this is a security matter since systemd journal logs are permissioned off per-user anyway. If the user is root, they could also just as well be reading the tmpdir that stores the clipboard contents.

I do however agree that the spam is not necessary in normal usage. I think it probably makes sense to gate this behind CM_DEBUG using the debug function. Let me know what you think about that. :-)

[markstos]

I agree this is a security/privacy issue because it could cause the clipboard contents to persist far longer then intended. Systemd logs might go into a backup that persist for a quite a long time-- not what I would expect for clipboard history.

I agree with the idea that the clipboard contents should stay out of the log files unless debug mode is enabled.

[markstos]

I'm running the latest version from Git and I still see clipboard entries in my systemd journal when running clipmenud as a systemd user service:

Oct 28 21:16:47 mark-xps.rideamigos.com systemd[20401]: Started Clipmenu daemon.
Oct 28 21:16:48 mark-xps.rideamigos.com clipmenud[12471]:  My first selection
Oct 28 21:16:48 mark-xps.rideamigos.com clipmenud[12471]: xsel: error opening logfile /dev/stderr for writing: No such
Oct 28 21:17:34 mark-xps.rideamigos.com clipmenud[12471]:  My second selection

There are also the warnings or errors about /dev/stderr (On Ubuntu 17.10), but it seems work despite those.

[cdown]

35a3cb2 should fix your problems with /dev/stderr.

As for writing out the selection... I'm not sure what's causing that and can't repro with the develop branch. Can you show me these while running with bash -x so I can see what causes that line to be written?

[markstos]

@cdown With the last patch, I still get the same kind of error, it's just about not being able to find /proc/self/fd/2. The file exists on my system, but I believe systemd is preventing it from being accessible.

I ran with bash -x, which pinpointed where the selection is being printed from:

Oct 28 22:18:12 mark-xps.rideamigos.com clipmenud[25496]: + timeout 1 xsel --logfile /proc/self/fd/2 -o --clipboard
Oct 28 22:18:12 mark-xps.rideamigos.com clipmenud[25496]: + timeout 1 xsel --logfile /proc/self/fd/2 -i --clipboard
Oct 28 22:18:12 mark-xps.rideamigos.com clipmenud[25496]: MY CLIPBOARD CONTENTS
Oct 28 22:18:12 mark-xps.rideamigos.com clipmenud[25496]: xsel: error opening logfile /proc/self/fd/2 for writing: No such device or address

Are you testing with the clipboard running as a systemd user service?

[cdown]

I'll file two new issues for these, #54 and #53.