Hi there,

I have a user called http and i want to make that user have access to my newly created user called adverts crontab so i can create events in the cron using my account http on behalf of adverts.
Below is the commands i did attempting but no luck.
Says :
must be privileged to use -u.
How do i make myself privileged?
Thanks!

My attempt:
groupadd editcrons
usermod -a -G editcrons http
usermod -a -G editcrons adverts
chown :editcrons /var/spool/cron/adverts
chown adverts /var/spool/cron/adverts
ls -l /var/spool/cron/adverts
-rw------- 1 adverts editcrons 44 Sep 29 10:51 /var/spool/cron/adverts
sudo chmod -R g+w /var/spool/cron/adverts
ls -l /var/spool/cron/adverts
-rw--w---- 1 adverts editcrons 44 Sep 29 10:51 /var/spool/cron/adverts
sudo chmod -R g+w+r /var/spool/cron/adverts
ls -l /var/spool/cron/adverts
-rw-rw---- 1 adverts editcrons 44 Sep 29 10:51 /var/spool/cron/adverts

A cron job could run any script or program as that other user. So if you allow the first account to decide the second account's cron jobs, you are letting that first account have carte blanche over that second account. Then I would have to ask what is the point of having a second account?

What tasks are you trying to accomplish?

The tool "sudo" can be modified using the file /etc/sudoers to allow a specific user to run specific commands with defined parameters as another user. Maybe that would be more helpful if any tasks need to be done as that other account.

I have cronjobs in my first account which i dont want to touch as they are doing different type of jobs so i want to have another space to store cronjobs so i created the second account. I have a php script to add or remove cron jobs and that will interfere then if i have it all on one account.

The aim is: http user has cron jobs set and my page: scheduler.php adds schedules to that. I now have another page called ads.php which i am trying to add events to trigger in there to apply ads etc. My servers user is http so if i use: shell_exec("crontab -r"); to remove all the crons then it removes all the crons for the http user (again, messes up my whole system i have going which works). So i want to remove all crons in the new account adverts and i am trying to do it with: shell_exec("crontab -r -u adverts"); but no luck. I dont have permission.

How would i go about giving the user http full access over the account adverts? The account adverts will never be used apart from its crontab. I just want http to access and pretty much control all its crontab events.
Let me know if thats possible thanks!

P.s: I tried using sudo, in my /etc/sudoers i added: http ALL=(ALL) NOPASSWD: ALL and then tried to complete the task with: shell_exec("/usr/bin/sudo crontab -r -u adverts"); but still no luck. The sudo doesnt seem to be triggering.

Ok. Thanks.

The /etc/sudoers line you listed above gives root access to the whole machine to the user http and your shell_exec function, and thus it could potentially zap the root crontab instead of the adverts crontab as well as is a general risk.

What you probably want would be something more like this:

You might skim through the manual page for sudoers to see if you can interpret that line or if you spot anything useful. But it should allow the following with PHP:

If you pass any variables to the shell, be sure that they are 'sanitized' so you avoid bad surprises.

Anyway, "sudo" is very, very useful and very, very powerful. I'd recommend the book "Sudo Mastery" by Michael W Lucas to get the proper background information about how to safely use it. The manual page for "sudoers" will make a lot more sense after reading the book.

1 members found this post helpful.

The better way to do it is use a root entry crontab - and that crontab entry uses crontab -u .

But having your account used by httpd is just asking for trouble. If the web server gets compromised, so is the other account.

And the next time you login you might not have the same executables you used to use...

The normal way to do it is to set a directory that the web server has only group access (and no write). Then your account (with group access) can write to it creating read only files for the web server.

This way you keep control over YOUR crontab, and the web server doesn't need any (another security failure there).

You can then create as many accounts as member of the shared group - with the understanding that the files to be put there are group read only (directories may be group rx).

This partitioning protects the accounts, AND prevents the web server from gaining a shell access if it gets hacked. AND it prevents a hacked web server from altering the contents of the directory.

Sudo: you're doing it wrong - PDF seems prudent here.

fascinating.

which still give access to the entire system (all you have to do is specify "root" as the user and you get to run anything as root).

1 members found this post helpful.

The part in the parentheses prevents that and limits "sudo" to acting as the user adverts for just that one command and no others. The only liability I see with that set up is that the cron job can be set up to run any scripts or commands as the user adverts. Perhaps it is better tightened down further to allow http to only clear the crontab:

That presumes that adverts itself will fill the crontab on its own.

I still think giving only group access is much more secure. Allowing a hacked web server to access cron still gives shell access.

Hi there,

Issue was that i needed to give full paths to the commands. Example: /usr/bin/sudo /usr/bin/crontab
All worked! I only realized yous gave me that result by refreshing moments ago but was too late as i figured it out haha.

Thanks very much! Really appreciate it I will use some of the tips above with the sudoers config
Cheers!

Ok. Great that it's working.

Yes, access to cron gives shell access, as hinted perhaps too indirectly in #2 above.

irishwill2008, I also agree with jpollard about the groups. You might see how much can be done without using crontab at all.