Normal users of cron should not have /sbin & /usr/sbin in path by default
Opened this issue · 7 comments
Can I please understand the reason why cron is suddenly, in fedora (FC40),
giving "normal" users a PATH that includes /sbin & /usr/sbin?
There does not seem to be a really valid reason for this & it could be something
that creates unexpected problems. Normal users should not really have sbin in
their path.
Fedora rejected,
https://bugzilla.redhat.com/show_bug.cgi?id=2292893
as being an "upstream change"...
It seems to be due to,
Commit 7575e75
Using _PATH_STDPATH instead of _PATH_DEFPATH
Please help me understand this!
The bin/sbin split is a historic artifact. Many utilities in sbin are useful for regular users and furthermore cron jobs as run by the root user might very well need to run also some of them which are not so useful for regular users.
You can override the path by putting this in /etc/sysconfig/crond
# Settings for the CRON daemon.
# CRONDARGS= : any extra command-line startup arguments for crond
CRONDARGS=-P
PATH=/usr/bin:/bin
@intc might want to add some more information as he opened the original pull request that changed this.
I agree with @t8m. Can't see any reason why these folders should not be in the PATH. Btw. PATH is not a security construct of any sort. I wonder if @freebsdfrau would have anything to add to this discussion?
OK, so I'll try to rephrase the question, because I just don't get the "I don't see a problem with it"
reasoning...
What was the imperative, at the time, to include paths that for >50 years (in Unix/cron) were left for the user to
set if they required them. (Noting that it's really easy for the user to set PATH in the cron job)
Suddenly there is an imperative to have them 9/sbin /usr/sbin) there for normal users by default?
What is it?
I'd like to understand it.
9 above should be an open parentheses.
There was no imperative, however things change in Linux/UNIX world and this is certainly more convenient.
See for example:
https://x.com/freebsdfrau/status/1554598491036323840
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617898
Anyway, I am not going to revert this unless there are very strong arguments why this presents a security issue of some sort.
Historical, yes, change happens, most humans don't like it when it affects them badly but eventually live with it.
What's important is that the change is generally good for everyone.
Seems to me the "2" variables in the code _PATH_DEFPATH_ROOT & _PATH_DEFPATH are there for a purpose
& it seems that at sometime that purpose has been "lost" in the maintenance.
Or is it perhaps inherited/copied from vixie-cron?
I have no problem with it that the default PATH of cron should include /sbin and /usr/sbin for the root user.
The concern is for normal users & obviously it's "convenient", but should they be allowed to find out
such nuances or are the maintainers just fed up with people reporting it as a bug? (hence the convenience
aspect for them & the users?)
That /sbin and /usr/sbin are usually symlinks (on all nix's now?) would indicate that one could be removed,
& that applies to /bin & /usr/bin will they? when? is that included in the cron maintainers thinking?
So let's not muck around lets make it consistent, whatever that is for the future! (hopefully there's a "plan")
Which brings up the question...
Will /usr/local/{bin,sbin} be included? or is the thinking that really is up to the user?
As I said I want to understand why this happened - I'm not going to rant that it should be reverted.
That is a matter for those that do maintain it. I'll change my paths to suit me.
But I do wonder if the shell default path will also soon include /sbin and /usr/sbin because it's convenient.
Is it a security problem? Not immediately & maybe never, it often takes 2 bugs to tango...