[GE users] Permissions for active_jobs/job_scripts directories

Esteban Freire esfreire at cesga.es
Fri Oct 31 09:28:33 GMT 2008

    [ The following text is in the "ISO-8859-1" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some special characters may be displayed incorrectly. ]

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, 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.

Today, we're going to try install SGE with Berkeley DB spooling instead 
of classic spool, 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.

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:
> #!/bin/sh
> 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.
>> $SGE_ROOT/default/spool/compute*
>> 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
>> $SGE_ROOT/default/spool/qmaster
>> drwxr-xr-x   2 root root   12288 Oct 27 10:12 job_scripts
>> Thanks in advance,
>> Esteban
>> ---------------------------------------------------------------------

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 mailing list