[GE users] Permissions for active_jobs/job_scripts directories
esfreire at cesga.es
Fri Oct 31 13:36:14 GMT 2008
Thanks for this useful information. We will try SGE + berkelyDB as you
> Hi Esteban,
> Am 31.10.2008 um 10:28 schrieb Esteban Freire:
>> Hi Reuti,
>> I would like comment you some doubts. We have been testing prolog
>> script on the execution_hosts and it's exactly what we want.
>> But we still see an issue, when a job is submitted, while it's in
>> state *qw*, the content for the job is on
>> *$SGE_ROOT/default/spool/qmaster/job_scripts/job_ID* on the machine
>> that is running the qmaster, a possible solution could be put 700
>> permissions to *job_scripts* directory,
> As I suggested - great.
>> but I'd would like to know if I could do the same that in the
>> execution hosts, for example, configuring a prolog in the SGE global
>> configuration for do this, by the way, we don't use NFS and therefore
>> we don't have shared the $SGE_ROOT directory between the qmaster and
>> the execution hosts.
>> On the other hand, we tried to configure 700 permissions to
>> *job_scripts* directory,
>> but on the execution hosts, and this put the queue in error state.
> Correct, as the executing job script will be done be the user of the
> job. Therefore it must be tuned per file in this directory in the prolog.
>> Today, we're going to try install SGE with Berkeley DB spooling
>> instead of classic spool,
> You will still need to set the protections of one of the BDB files.
> Although they are binary, some users could peak inside.
> An easier approach: separate the submit and qmaster machine. On the
> qmaster machine you could put the qmaster spooling directory into
> /var/spool/sge/qmaster. When noone can login to the qmaster machine,
> noone can see the jobs.
>> I heard that you can configure *postgresgl* too, but I didn't find
>> enough information about it, and I don't understand if Postgres is
>> only used for the accounting, or it can be configured SGE + Postgres,
>> instead use Berkley DB. I would appreciate if you can indicate me
>> some link/web page, with more information about how configure this.
> For now it's only used in conjunction with ARCo. Somehow I remember
> slightly, that in former times SGE could be compiled to use Postgres
> for storing the spooling information. But maybe it was only to test
> it's integration before it was decided to use BDB .
> -- Reuti
>> Thank you very much,
>> Reuti wrote:
>>> Hi Esteban,
>>> Am 27.10.2008 um 10:29 schrieb Esteban Freire:
>>>> Hello all,
>>>> Checking the permissions for active_jobs/jobs and active_jobs under
>>>> 'qmaster' or 'compute*' directories, we have seen that this
>>>> directories can be read by all users on the node and therefore this
>>>> is not secure for us, because in principle, it would be interesting
>>>> that an user cannot read the job of another user.
>>> correct. That's the way it's implemented. While for the qmaster
>>> spool directory you could change the permissions of the directory to
>>> avoid it (or use SGE 6.2 with Berkeley DB spooling), I'm not aware
>>> of the option to change it for the execution node with a simple
>>> default setting.
>>> Nevertheless: you could use a queue prolog to change the protection
>>> of the job just before the job starts. Chances are low, that in this
>>> short timeframe anyone can get access script:
>>> chown $USER $JOB_SCRIPT
>>> chgrp `id $USER -gn` $JOB_SCRIPT
>>> chmod o= $JOB_SCRIPT
>>> exit 0
>>> This prolog must be defined in the queue definition to also execute
>>> as root, i.e. "root at all.q.prolog" or alike.
>>> -- Reuti
>>>> Maybe, we didn't install SGE correctly, or it's necessary indicate
>>>> something on the scheduler or global configuration, or doing the
>>>> installation indicating an extra parameter.
>>>> I would appreciate if someone could help me with this.
>>>> drwxr-xr-x 4 root root 4096 Oct 27 09:17 active_jobs
>>>> drwxr-xr-x 3 root root 4096 Oct 27 08:56 jobs
>>>> drwxr-xr-x 2 root root 4096 Oct 27 09:17 active_jobs
>>>> drwxr-xr-x 2 root root 12288 Oct 27 10:12 job_scripts
>>>> Thanks in advance,
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net
More information about the gridengine-users