[SOLVED] Change default cron path for a user without home

[kgdrenefort]

Hello,

as the topic says, I have an user without home, should not have one.

I can't define a crontab for it, because this user don't have a home.

I'll try systemd timer another time, for now I would like to have a working cron for this user.

For root, it works indeed since it have a home dir, but this user report this error after saving a cron file:

Code: Select all

$ LC_ALL=C crontab -e
crontab: installing new crontab
/home/srvadm/.cache/crontab: mkdir: No such file or directory

After some research, I can't found a way to move this path to another one I need.

I use cronie.

Any ideas ?

PS : I want to avoid to run this from root as this user, but if there is no other choices…

Regards,
GASPARD DE RENEFORT Kévin

[RumpletonBongworth]

Hello, as the topic says, I have an user without home, should not have one.

Firstly, why should it not have a valid home directory? Is there a substantive technical reason?

As did the person who opened this thread, you have found that there can sometimes be adverse consequences for specifying a home directory that is invalid. In your case, the situation is worse because crontab(1) wants to be able to use a transient directory to back up the existing crontab, if any. To quote its man page:

On edition or deletion of the crontab, a backup of the last crontab will be saved to $XDG_CACHE_HOME/crontab/crontab.bak or $XDG_CACHE_HOME/crontab/crontab.<user>.bak if -u is used. If the XDG_CACHE_HOME environment variable is not set, $HOME/.cache will be used instead.

Note that the English is a little off there. It should really begin with something like "Upon editing or deleting the crontab". As I see it, you have three options at your disposal. I'll list them in what I believe to be reverse order of desirability.

Option #1: The obviously correct solution: create and assign a valid home directory. Metaphorically speaking, stop trying to push the door that's labelled pull.

Option #2: Attempt to persuade the cronie maintainers to have an option whereby the creation of the backup can be suppressed.

Option #3: Falsify XDG_CACHE_HOME in the environment of crontab(1) at the time of executing it. To do this would seem silly as it would only highlight the fact that crontab(1) wants to be able to stash a backup to a user-writeable directory using a predictable relative path to begin with. Even if you were to falsify it as, say, /tmp, there would be side effects. In particular, it would not scale beyond being applicable to one single user bearing an invalid home directory (there might well be a conflict of ownership).

[kgdrenefort]

Hello,

For context, I need / want an user to manage some tasks on my servers and, possibly, with the less permissions and ownership necessary.

Thus, I did not wanted this one to get a home directory (because until cronie, it wasn't necessary).

But from your explaination and some more research, it seems you are right and have reached a point where this user need a home directory.

It's not a problem, I wanted to avoid that behaviour if possible, if it's not a good idea I'll add to this user the home directory needed for cronie.

#1 is far better and taking more sense than #2 and specially #3. 

Thanks for your time and knowledge.

PS : For the record and future reader, don't use usermod -m -d /home/user user to add it. Simply create the directory and set ownership to user:user, then it uses it by default if the user was created and trying to point things out by default, as my cron working now.

Regards,
GASPARD DE RENEFORT Kévin

[szatox]

I can't define a crontab for it, because this user don't have a home.

That's weird, I never heard of crontabs being stored in user's home directory. My cronie uses /var/spool/cron/crontabs/ for that.

It is also possible to use /etc/crontab, the system crontab uses a slightly different syntax than user crontab and it actually has a field for specifying the username that should run the job.

Firstly, why should it not have a valid home directory? Is there a substantive technical reason?

Sometimes programs are not supposed to store any data at all and only need an UID.
It not only allows you to restrict access to files, but also do some other tricks like traffic shaping with iptables matching connections against process owner. Running things with a changed user is a great, underappreciated trick we don't use nearly often enough.

[RumpletonBongworth]

Just to add that you can also chmod the home directory with a mode of 700, in case you're worried about some other process running as the "srvadm" user ever writing something there that should not be seen by processes running as other users.