I think this is a good idea. Start with /home/admin or /home/a/admin for that matter and extend it later.
the run-crons script does not switch users, the user running the scripts has been defined in the /etc/crontab file. In some way this resembles our setup: cron-daemon checks system crontab and user crontabs and executes jobs in system crontab with configured user and in user crontab with the specific user rights. The /etc/cron.d directories are a helper, executed by another service that runs with configurable permissions. regards, Lars On Fri, Dec 19, 2008 at 4:56 PM, Bertrand Delacretaz <[email protected]> wrote: > On Fri, Dec 19, 2008 at 4:38 PM, Lars Trieloff <[email protected]> wrote: >> I doubt that. On my Gentoo box with Vixie-Cron I can find following >> statements in the crontab: >> >> */10 * * * * root test -x /usr/sbin/run-crons && /usr/sbin/run-crons >> >> which means it is more or less hardcoded that root runs the script, >> and relys on the correct system setup.... > > I don't know this run-crons script but if it runs scripts for users > other than root it might as well use the script's user owner identity. > > Anyway, my observation applies to the general case of running a script > outside of the context of a request. > > As others have suggested, requiring that such scripts be placed inside > a user's home folder, and assuming that that folder is properly > secured, is probably the easiest way to define the identity under > which to run the script. > > An additional safety feature might be to only accept scripts that have > specific access rights, for example "only writable by owner". > > If we want to use non-request scripts only for admin initially, we > might require them to be stored under /home/admin, so that we can > later allow other users as well. > > -Bertrand > >> On Fri, Dec 19, 2008 at 2:31 PM, Alexander Klimetschek <[email protected]> >> wrote: >>> Not exactly. To cite Bertrand: >>> >>> Unixish systems solve this by using the identity of the user who owns >>> the script (unless the setuid flag is set), and enforcing the way this >>> identity can be set - but we don't have that kind of feature in JCR, >>> or do we? >
