I'm root, and I saw there are a lot of contents in /etc/crontab, which I thought is the root's cron job configurations. When I use crontab -e, I saw nothing in the editor; after I quit crontab -e, what I added was not found in /etc/crontab. So, where is root's cron job configuration stored? And other users?
It is stored in the directory:
/var/spool/cron/crontabs
Containing one file per user.
From man crontab (at least on my Ubuntu 13):
There is one file for each user's crontab under the
/var/spool/cron/crontabs directory. Users are not allowed to edit the
files under that directory directly to ensure that only users allowed
by the system to run periodic tasks can add them, and only
syntactically correct crontabs will be written there. This is
enforced by having the directory writable only by the crontab group
and configuring crontab command with the setgid bid set for that
specific group.
It is distribution-dependant, but mostly it is in /var/spool/crontab/<username>.
For those looking for Fedora/CentOS/RHES, it's:
/var/spool/cron/<username>
Related
I configured my server as cPanel, CloudLinux, LiteSpeed, CWAF, CageFS, CXS.
All my services are running smoothly.
However, I can create a cronjob from one user and access other users' files symbolically.
For example, I can read the config.php file in user2's public_html folder by adding a cron to user1 as follows.
ln -s /home/user2/public_html/config.php config.txt
When cron runs in this way, a shortcut in the form of config.txt occurs on user1. When we view this config.txt file, the contents of the config.php file on user2 appear.
This is a very large vulnerability, how can I prevent this?
My English is not good. Forgive me.
thanks
How exactly are you reading this file after the symlink has been created? Because it doesn't work on any of the cPanel servers I've tested.
Additionally, the cronjob is executed as the user, so I'm not sure how this would allow an escalation to happen, because it would be similar to executing it in a shell anyway.
If you're within the user1's jail (su - user1), add a cronjob such as:
0 * * * * ln -s /home/user2/public_html/wp-config.php /home/user1/config.txt
Whenever the symlink is actually created, and you then do a cat /home/user1/config.txt as user1, you'll end up with a 'No such file or directory':
cat: config.txt: No such file or directory
Why? Because you're creating a symlink that points to a file that doesn't exist (within CageFS).
But if you're absolutely sure that it's possible (despite not being able to replicate it), then report it to CloudLinux, because it would clearly be something they'd have to fix.
Heck, I'm surprised you didn't create a ticket with them in the first place, and instead decide to go to Stackoverflow to bring up your issue.
my_cron-file works when it's created directly in /etc/cron.d/:
sudo nano /etc/cron.d/my_cron
# Add content:
* * * * * username /path/to/python /path/to/file 2>/path/to/log
But it doesn't work when I copy/move it to the directory:
sudo cp ./my_cron /etc/cron.d/my_cron
ls -l /etc/cron.d outputs the same permissions both times: -rw-r--r--. The files are owned by root.
The only reason I could imagine at the moment is that I've to refresh/activate something after copying, which happens automatically on creation.
Tested on Ubuntu and Raspbian.
Any idea? Thanks!
Older cron daemons used to examine /etc/cron.d for updated content only when they saw that the last-modified timestamp of that directory, or of the /etc/crontab file, had changed since the last time cron scanned it. Recent cron daemons also examine the timestamps of the individual files in /etc/cron.d but maybe you're dealing with an old one here.
If you have an old cron, then if you copied a brand new file into /etc/cron.d then the directory's timestamp should change and cron should notice the new file.
However, if your cp was merely overwriting an existing file then that would not change the directory timestamp and cron would not pick up the new file content.
Editing a file in-place in /etc/cron.d would not necessarily update the directory timestamp, but some editors (certainly vi, unless you've configured it otherwise) will create temporary working files and perhaps a backup file in the directory where the file being edited lives. The creation and deletion of those other files will cause the directory timestamp to be updated, and that will cause cron to put the edited file into effect. This could explain why editing behaves differently for you than cp'ing does.
To force a timestamp to be updated you could do something like sudo touch /etc/crontab or create and immediately remove a scratch file (or a directory) in /etc/cron.d after you've cp'ed or rm'ed a file in there. Obviously touch is easier. If you want to go the create+delete route then mktemp would be a good tool to use for that, in order to avoid clobbering someone else's legitimate file.
If you were really paranoid, you'd wait at least a second between making file changes and then doing whatever you choose to do to force a timestamp update. That should avoid the situation where a cron rescan, your file updates, and your touch or scratch create+delete could all happen within the granularity of the timestamp.
If you want to see what your cron is actually doing, you can sudo strace -p <pid-of-cron>. Mostly it sleeps for a minute at a time, but you'll see it stat some files and directories (including /etc/crontab and /etc/cron.d) each time it wakes up. And of course if it decides that it needs to run a job, you'll see that activity too.
I have a QNAP NAS running Google Drive sync so that my QNAP, Computers and Google Drive are all in Sync.
When I create a file on my work computer and get home to the QNAP I get an access denied error on the file I created at work.
If I view the permissions I can see they are set incorrectly. From the QNAP web manager I simply right click the folder containing my files and set permissions to "Reapply and apply to subfolders/files".
How would one go about doing the above via a cron job that runs say every 5 minutes?
I had a similar problem myself and also made a cron job for it.
start of with making a script in a easy to find place.
I used "/share/MD0_DATA/" because all the shares live here.
Create a file like perms.sh and add the following:
#!/bin/bash
cd /share/MD0_DATA/(folder you want to apply this)
chmod -R 775 *
chown -R nobody:nogroup *
I used the nobody:nogroup just for example you can use any user and group you want.
Now you need to add this script to crontab.
To see whats in your crontab use:
crontab -l
to edit the crontab use:
crontab -e
This editor works like vi if you don't like vi and want to access the file directly edit:
/etc/config/crontab
Add this line to your crontab:
*/5 * * * * /share/MD0_DATA/perms.sh
The 5 represents a 5 minute interval.
Then you need to let crontab know about the new commands:
crontab /etc/config/crontab
I hope this helped you.
Have made backup script that does well: makes backup zip-file and then uploads it via ftp to another server. It's located here: /home/www/web5/backup/backup
Then I decided to put this script into crontab to be done automatically.
I'm doing (as root)
crontab -e
On the blank row I put:
*/1 * * * * /home/www/web5/backup/backup
Escape key, :wq!, Enter
I set it to be done each minute to test it.
Then went to the FTP folder, where script uploads the files. I'm waiting, but nothing happens: catalog is empty after each refresh in my Total Commander.
But when I execute /home/www/web5/backup/backup manually (as root as well), it works just fine and I see the new file at FTP.
What's wrong? This server is kind of heritage, so I might know not everything about it. Where to check first? OS is
Linux s090 2.6.18.8-0.13-default
(kind of very old CentOS).
Thanks for any help!
UPD: /home/www/web5/backup/backup has chmod 777
UPD2: /var/log/cron doesn't exist. But /var/log/ directory exists and contains logs of apache, mail, etc.
*/1 may be the problem. Just use *.
* * * * * /home/www/web5/backup/backup
Also, make sure /home/www/web5/backup/backup is executable with chmod 775 /home/www/web5/backup/backup
Check /var/log/cron as well. That may show errors leading to a fix.
From Crontab – Quick Reference
Crontab Environment
cron invokes the command from the user’s HOME
directory with the shell, (/usr/bin/sh). cron supplies a default
environment for every shell, defining:
HOME=user’s-home-directory
LOGNAME=user’s-login-id
PATH=/usr/bin:/usr/sbin:.
SHELL=/usr/bin/sh
Users who desire to have their .profile executed must explicitly do so
in the crontab entry or in a script called by the entry.
This should be pretty straight forward but I can't seem to get getting it working despite reading several tutorials via Google, Stackoverflow and the man page.
I created a cron to run every 1 min (for testing) and all it basically does is spit out the date.
crontab -l
* * * * * /var/test/cron-test.sh
The cron-test file is:
echo "$(date): cron job run" >> test.log
Waiting many minutes and I never see a test.log file.
I can call the "test.sh" manually and get it to output & append.
I'm wondering what I'm missing? I'm also doing this as root. I wonder if I'm miss-understanding something about root's location? Is my path messed up because it's appending some kind of home directory to it?
Thanks!
UPDATE -----------------
It does appear that I'm not following something with the directory path. If I change directory to root's home directory:
# cd
I see my output file "test.log" with all the dates printed out every minute.
So, I will update my question to be, what am I miss-understanding about the /path? Is there a term I need to use to have it start from the root directory?
Cheers!
UPDATE 2 -----------------
Ok, so I got what I was missing.
The script to setup crontab was working right. It was finding the file relative to the root directory. ie:
* * * * * /var/test/cron-test.sh
But the "cron-test.sh" file was not set relative to the root directory. Thus, when "root" ran the script, it dumped it back into "root's" home directory. My thinking was that since the script was being run in "/var/test/" that the file would also be dumped in "/var/test/".
Instead, I need to set the location in the script file to dump it out correctly.
echo "$(date): cron job run" >> /var/test/test.log
And that works.
You have not provided any path for test.log so it will be created in the current path(which is the home directory of the user by default).
You should update your script and provide the full path, e.g:
echo "$(date): cron job run" >> /var/log/test.log
To restate the answer you gave yourself more explicitely: cronjobs are started in the home directory of the executing user, in your case root. That's why a relative file ended up in ~root.