Editing of the Root-User (maybe any other user) Crontab not possible under Lion

[GoogleCodeExporter]

At my company we use a cron'd shell script to backup our software's mysql 
database. So far we customised the schedule the script runs by using CronniX 
with great success and ease. As the shell script needs root level privileges we 
enter the schedule in the root-user's crontab. During our Lion-Testing we 
encountered an issue that apparently makes it impossible to edit the root 
crontab, or maybe any other user's crontab. Seemingly an included binary called 
'sucrontab' is only available in a PowerPC version, which is rendered useless 
under Lion, since there is no more support for PowerPC-Code.

Is there maybe a Intel version of this binary, or maybe another solution?

See attached screenshots for further info.

Regards,
Steve

Original issue reported on code.google.com by macp...@gmail.com on 18 Aug 2011 at 7:10

Attachments:

• shot_01.png
• shot_02.png

[GoogleCodeExporter]

Steve, thanks for reporting this. This is indeed a problem on Lion that I 
hadn't anticipated. I'll have to see if sucrontab can be recompiled.

Cheers,
Sven

Original comment by sven.a.s...@gmail.com on 19 Aug 2011 at 4:00

• Changed state: Accepted

[GoogleCodeExporter]

I've had a look and unfortunately, I seem to have lost the sources to 
sucrontab. While it was a very simple cli application, I cannot rewrite and 
test this at this time.

My only recommendation is to save a crontab as text and install it as a certain 
user manually on the command line:
 sudo crontab -u some_user crontab.txt

Or simply put your tasks in the system crontab (provided that doesn't rely on 
sucrontab as well).

I'll try to update CronniX for full Lion compatibility as soon as I can (but it 
won't be soon, I'm afraid). Sorry for the inconvenience!

Cheers,
Sven

Original comment by sven.a.s...@gmail.com on 23 Aug 2011 at 12:09

[GoogleCodeExporter]

Issue 12 has been merged into this issue.

Original comment by sven.a.s...@gmail.com on 10 Nov 2011 at 9:25

[GoogleCodeExporter]

If you outline what the "sucrontab" command line application did then I would 
be happy to assist with the re-write and testing. 

Below is the usage for the application : 

usage: crontab [-u user] file
       crontab [-u user] { -e | -l | -r }

Are you able to elaborate on the -e, -l and -r arguments (eg. what they do)?

Original comment by henri.sh...@gmail.com on 8 Jan 2012 at 7:19

[GoogleCodeExporter]

From the crontab man:

     -l      Display the current crontab on standard output.

     -r      Remove the current crontab.

     -e      Edit the current crontab using the editor specified by the VISUAL
             or EDITOR environment variables.  The specified editor must edit
             the file in place; any editor that unlinks the file and recreates
             it cannot be used.  After you exit from the editor, the modified
             crontab will be installed automatically.

Original comment by janetvar...@gmail.com on 8 Jan 2012 at 9:36

[GoogleCodeExporter]

Thanks for your offer, Henri! The relevant calls to "sucrontab" are:

  sucrontab -u some_username -l

and

  sucrontab -u some_username - < data

for reading and for writing other users' crontabs respectively. Note that the 
latter reads the crontab data from stdin. The relevant calls to the sucrontab 
binary are in "crController.m".

I should note that sucrontab was pretty much a hack at the time, because the 
security frameworks weren't really well developed then (or my understanding of 
them ;). Ideally a new solution would avoid embedding a binary with the sudo 
bit entirely.

Cheers,
Sven

Original comment by sven.a.s...@gmail.com on 9 Jan 2012 at 8:42

[GoogleCodeExporter]

Thanks for the details regarding the calls to the sucrontab command and also 
from which part of the project they are made from. I agree, that avoiding use 
of the sudo bit would be a good idea. However, I Imagine that such a change 
will require some additional modifications to the rest of the project?

As a starting point do you think it makes sense to get this working again under 
Lion with a direct replacement binary or would you prefer to look at using the 
provided Mac OS security frameworks?

Also, off the top of your head will Cronnix load the new crontab or should a 
tool such as crontab be used to perform the edit? Any direction in that regard 
would be helpful. Also, if you remember anything else about the utility that 
would help with the re-write then please let me know. Provided that simply 
re-writitng that tool is the desired approach.

Thanks. 
Henri 

Original comment by henri.sh...@gmail.com on 12 Jan 2012 at 1:21

[GoogleCodeExporter]

Henri, sorry for the late reply.

The impact to the rest of the project would be minimal. If the code were 
provided in a separate class, one would just have to update two methods in 
crController: writeSystemCrontab and writeUserCrontab.

The problem with a replacement binary is that I cannot include simply a binary. 
At the very least I'd need the source code to review and build it myself before 
inclusion. In that regard I think the effort is better spent on a "proper" 
solution w/o a +s binary.

I'm not sure I fully understand your last question. CronniX is using the 
crontab tool to read and write crontabs already. It's simply a visual editor 
for crontab and pipes everything through the crontab binary. "sucrontab" was 
essentially "super user crontab" that did what crontab does, just with super 
user permissions.

Hope that helps!

Sven

Original comment by sven.a.s...@gmail.com on 20 Jan 2012 at 9:52

[GoogleCodeExporter]

Firstly, apologies for the late reply. 

I recently started investigating ways to accomplish an authenticated dialog 
from a command line tool. It turns out that unless you start signing code you 
have to use a depreciated method (10.7 and later). From a security standpoint 
this depreciation makes perfect sense. However, I am unsure if you want to 
start signing the code for the Cronnix project.

Next, rather than re-inventing the wheel I thought it would be a good idea to 
check if there was an existing tool or helper tool which could be a drop in 
replacement or at least make development faster. Assuming that you are not 
planning to go down the code signing path, enter 'cocoasudo'.

 - <https://github.com/performantdesign/cocoasudo>
 - <http://www.performantdesign.com/2009/10/26/cocoasudo-a-graphical-cocoa-based-alternative-to-sudo/>

I have yet to look at the source code of cocoasudo in any detail. Prior to 
including the cocoasudo project into Cronnix, I susggest auditing the cocoasudo 
project for any glaring security related issues. Cronnix is licensed under the 
GNUGPL and cocoasudo is released under the Apache licence. I am not 100% 
positive on this, but I am fairly sure that the binary for cocoasudo could be 
distributed within the Cronnix project without any issues. More information on 
the Apache Licence is available from : 
http://en.wikipedia.org/wiki/Apache_License

Unfortunately cocoasudo has not been maintained and as such it is not working 
from my research. The source code is available on GitHub should someone wish to 
look at fixing this project. In addition, there was another issue I found with 
cocoasudo, which probably should be addressed (in the event that it the project 
is fixed to work on 10.6/10.7/10.8); cocoasudo seems to provide a return code 
of zero even when the sub-command executed has a non zero return code.

Another project which looks promising called gksudo 
<http://gksudo.sourceforge.net/>. However, the SVN repository at contains zero 
files at present. As such, until this project is developed further this project 
is not going to help.

The other approach which is quite straight forward is to use AppleScript to 
escalate the privileges. I suspect that this will not be compatible with code 
signing and as such will use a depreciated meathod. I do not know how 
AppleScript escalates the privileges behind the scenes or if there are 
additional options which may be passed provided within Apple Script during 
privilege escalation. For example, I do not know if it is possible to specify 
the name of the program making the request, as such using AppleScript to 
elevate privileges with the attached example means that the name 'osascript' is 
seen in the dialog box which is presented to the user rather than 'Cronnix'.

In conclusion, I see two obvious approaches (assuming that bundling the Apple 
Script within the Cronnix project is a way forward) :

  (Approach #1) : Write a replacement sucrontab which could then call osascript (example included as attachment).
  (Approach #2) : Call osascript directly from within Cronnix.

I have two questions with regards how to proceed : 

 (Question #1) : What are your thoughts with regards using AppleScript for privilege esculation?
 (Question #2) : Assuming that you feel using Apple Script, then would you like to call it directly or to have a replacement tool called sucrontab which in turn calls osacript (example attached)?

Please let me know how you would like to proceed when you have a moment.

In the mean time, I have attached a zip file which contains a proof of concept 
using AppleScript. This should be able to be used as a drop in replacement for 
sucrontab. However, during my testing this did not actually work. Although from 
the command line it seemed to work perfectly.

Also, please note that the proof of concept included with the attachment is not 
a binary compiled from C source code, it is a shell script written in BASH. 
This potentially introduces further security issues which may need to be 
addressed. Certainly, Apples approach to code signing around privilege 
escalation makes a lot of sense from a security stand point. 

When I dropped the AppleScript based sucrontab file into place within Cronnix, 
although authentication was requested by osascript the root crontab was not 
displayed (and I know on this test system there were entries). As such, it is 
not quite ready as a drop in replacement. If you have any ideas as to why it is 
not working when dropped into place, then please let me know. The simple test I 
performed to load the root crontab using the drop in replacement is listed 
below : ./sucrontab -u root -l

When I run the AppleScript based sucrontab with the following command it seemed 
to prompt for authentication and then output the crontab for root.

The attachment also includes the testing code from my messing about with 
cocoasu, which put simply did not work. However, if anyone wants to look at the 
cocoasu source code then having that example project may be helpful for testing 
purposes.

In summary, the drop in replacement is not working. If you have any ideas as to 
the changes required either within Cronnix or within sucrontab then please let 
me know.

Thanks.
Henri 

Original comment by henri.sh...@gmail.com on 10 Mar 2013 at 9:46

Attachments:

• sucrontab.zip

[GoogleCodeExporter]

Hi Henri,

thanks for your update regarding this issue. Since I won't be able to look into 
this in detail in the foreseeable future I'm happy to accept any working 
solutions to fix this problem :) To make it easier, I'll try to find the time 
to move this project over to github where people can just fork and send pull 
requests. I'm not sure if there's something similar available over here.

Sorry for not being of more help at this time,
Sven

Original comment by sven.a.s...@gmail.com on 4 Apr 2013 at 10:31