This may be a trivial question, but I’ve searched the forum and beyond in vain.
I have some bash scripts I want to schedule like cron allows (at some hours, some days of the week, etc.). Alas ! Theses scripts are not designed to run fully in bakground : they need user inputs (password input or other interaction) and, if possible some graphical output (terminal execution, zenity dialogs).
It seems cron, “systemd timers” and at can’t be answers as I don’t want to bend display / create breach in security.
Even “gnome-scheduler” seems to suffer the same problem (not to mention it’s not available in Leap)
How would you do that safely ? I can waive the graphical stuffs but not the interaction.
But systemd timers (note that cron / at are now the same, they are still there for compatibility, but translated behind the scene) are run fully in the background.
They are started with a specific user as owner (you do not tell us which user, you only talk about “I”, which is not a concept the operating system knows about). And they do not know if that same user (or another) is logged in in the GUI and have no access to that session.
Think a moment about the impact on security when a random process would have access to a GUI session that happens to run at the same time. That process would be able to read all the key/mouse actions taken. all passwords typed, etc.
Graphical stuff is actually easy. So you can simply use any available GUI dialogs to request input. Whether it will be “safely” depends on your definition of “safely” and implementation.
Or you can use helper running as part of your session that interacts with your background programs. You may look at systemd password agents for inspiration. Actually, it just lacks usable user session password agent, so may be you could contribute it.
Think a moment about the impact on security when a random process would have access to a GUI session that happens to run at the same time. That process would be able to read all the key/mouse actions taken. all passwords typed, etc.
+
BTW, is this question not the same as this one: unable to run a graphical app via cron - #2 by hcvv ?
@hcvv You’re kidding me, right ? I know this, I even vote for and quote this old post in my first message of this topic
I’ll try to be more explicit then. I gave up the idea of cron and brothers because I don’t want any security hole or garbage between the sessions.
I just want a tool, or better a cli tip, to schedule automatic execution of my scripts, directly in the GUI standard user session (inside, as he’s logged in it) : like if this user was just prompt them in a bash/term.
Graphical stuff is actually easy. So you can simply use any available GUI dialogs to request input.
@arvidjaar Have you an advice to implement this ? An “easy” thing for me is to script a timer with a condition on date/time and a sleep loop but that would be awfully reinventing the weel (no to mention poor performance and zero style ).
Or you can use helper running as part of your session that interacts with your background programs.
Sorry, I don’t understand this one. Can you reformulate or explain ?
@vertclair just run a user systemd timer to trigger whatever your wanting to run, it will only run when the user is logged in (graphical.target). Script out what you want to run and test that first, then a timer and service should be the easy part…
An “easy” means that to access GUI your program just needs $DISPLAY and $XAUTHORITY. What your program does with them is up to you.
You have program that runs as part of your session and listens/monitors for events from your background program and serves as middle man between user and your background program. But that is overkill if your background program runs under your user’s session anyway.
Thanks you again @hcvv@arvidjaar & @malcolmlewis : I choose Malcom’s as the solution because it summarize the whole in a few words but you’re all awesome !
What’s wrong with systemd timers?
My bad : I thought it was the same “flaw” than cron/at, I didn’t understand it could run in graphical session as the user. Now your previous answers make sens for me.
An “easy” means that to access GUI your program just needs $DISPLAY and $XAUTHORITY. What your program does with them is up to you.
Timers are so elegant that it’s not even necessary to set/export theses explicitly in calls. The systemd environment ships the few I needed.
Finally, I manage to schedule and successfully running my scripts with user systemd timers.
If somebody else needs it, the doc is very good (but I think basic skills with services is better before) : Working with systemd Timers (direct link to “Using timers as a regular user” part but the whole page/chapter is useful).
Remark that from your first post it was not clear who “I” was. It is now clear that this is all about one and the same end-user. But very often people just say “I” and “my” where it they in fact talk about different users like root and some end-user, not understanding the multi-user and multi-session capacity of Unix/Linux.
You are right, I should have been more precise about this. I often take too much for granted the principle of least privilege. I said “I”/“my” to mention this stuff is executed in environment that I “control”/access but not to play with root privileges (otherwise, that would have been way simpler). But, indeed, this could have been with intermediary rights or for another user/session than mine. I will pay more attention for this informations in future post.
).
