[GE users] Grid 6.2 and script with sticky bit on

Juan Manuel Sanchez jmsanchez at gcs-iberia.com
Wed Nov 12 11:31:26 GMT 2008


Hi Reuti:

I installed a grid server in linux (sles10) to check if the problem is that the server grid running in solaris or linux but the problem is the same.

I enabled a linux to submit host and I changed the permission my script to can launch this script in linux :

-rwsr-xr-x   1 user1  group      61 Nov 11 12:09 test
-rwxr-xr-x   1 user1  group     470 Nov 12 11:29 test1

The script: test launch to test1 and this script launch the job to grid with qrsh.

And with this configuration is curious :

   if the script is launch since Solaris10 by user2 , the owner job is the propertie of script( user1)
   if the script is launch since Sles10 by user2 , the owner job is this user: user2 and not the propertie of script (user1) . Only in this situation it work fine.

According to this the problem is with Solaris 10 . I will continue investigating ...

BR, Juanma.
 
----- Original Message -----
From: reuti <reuti at staff.uni-marburg.de>
To: users at gridengine.sunsource.net
Sent: Tue, 11 Nov 2008 14:51:28 +0100 (CET)
Subject: Re: [GE users] Grid 6.2 and script with sticky bit on

Hi Juanma,

Am 11.11.2008 um 14:23 schrieb Juan Manuel Sanchez:

> I installed another server grid in other zone of solaris 10 and the  
> execution is the same. The owner of job is the owner of script with  
> suid.
>
> I review the process started in version 6.0 u08 when we launch a  
> job and I saw that exist one process that in version 6.2 not start.
>
> This is the sequence in 6.0u08:
>
> 1721  /opt/n1ge6/bin/sol-sparc64/sge_execd
>   18997 sge_shepherd-82112 -bg
>     18998 /opt/n1ge6/utilbin/sol-sparc64/rshd -l
>       18999 /opt/n1ge6/utilbin/sol-sparc64/qrsh_starter /opt/n1ge6/ 
> DEFAULT/spool/jupiter/activ
>         19000 tcsh -c setenv DISPLAY citrix1:17.0;/home/user2;set
> in this sequence the process 1721,18997 and 18998 are root owner  
> and 18999 is user2 owner.

so you see in 6.0u8 the SUID ignored on Solaris (for me the SUID is  
also working in 6.0u8 on Linux - but only for binaries - see below).

> But this the sequence in 6.2:
>
> 767   /opt/n1ge62/bin/sol-sparc64/sge_execd
>   6343  sge_shepherd-14 -bg
>     6344  /opt/n1ge62/utilbin/sol-sparc64/qrsh_starter /opt/n1ge62/ 
> DEFAULT/spool/jupiter/ac
>       6345  tcsh -c setenv DISPLAY citrix1:11.0;/home/user2;set
>
> in this sequence the process 767 , 6343 are root owner and 6345 is  
> user1 owner, the owner script suid enable.

you may see only the effective user. Usually the processes have an  
"effective" and a "real" user attached. For sure this can also be  
displayed with Solaris' "ps".

> You can see that in 6.0 u08 exist the (/opt/n1ge6/utilbin/sol- 
> sparc64/rshd -l) process and in 6.2 not exist. I think that this  
> process will change the owner of job.

This is correct for 6.2, as the builtin mechanism is used. You can  
fall back to the traditional startup method:

http://gridengine.sunsource.net/issues/show_bug.cgi?id=2757

(you will have to adapt it for Solaris).

Nevertheless, I can't really test it: in Linux a script must be  
readable, it can't have -rws--x--x. This only works there for  
binaries there.

-- Reuti

BTW: Why do you set the SUID, when you don't want it?


> BR. Juanma.
>
>
>
>
> ----- Original Message -----
> From: Juan Manuel Sanchez <jmsanchez at gcs-iberia.com>
> To: users at gridengine.sunsource.net
> Sent: Tue, 11 Nov 2008 12:43:39 +0100 (CET)
> Subject: Re: [GE users] Grid 6.2 and script with sticky bit on
>
> Hi Reuti:
>
> The gridserver is a zone in Solaris 10 and the old installation  
> also is a zone in Solaris10.
>
> The script with flag setuid and with this permission: rws--x--x  
> call to other script that have this permission: rwx--x--x and this  
> script launch the job to grid server with qrsh. That is necesary  
> because the secondary script make modifications in files with the  
> user suid administrator.
>
> I will check to reinstall the server grid in other zone and don't  
> migrate the queue and configuration from old version (6.0 u08) . I  
> think it's error will can be produce to translate the configuration  
> of other server.
>
> BR. Juanma.
>
>
>
> ----- Original Message -----
> From: reuti <reuti at staff.uni-marburg.de>
> To: users at gridengine.sunsource.net
> Sent: Mon, 10 Nov 2008 12:37:40 +0100 (CET)
> Subject: Re: [GE users] Grid 6.2 and script with sticky bit on
>
> Hi,
>
> Am 06.11.2008 um 15:02 schrieb Juan Manuel Sanchez:
>
>> Hi Reuti:
>>
>> The new installation and the old installation are in the same
>> directory. The mount is with setuid enable .
>>
>> mount|grep pub
>> /pub on mercurio:/DATA/pub remote/read/write/setuid/nodevices/soft/
>> intr/xattr/zone=gridsrv62/dev=5181bd1 on Thu Nov  6 14:50:00 2008
>>
>> I changed the script to other directory in other mount point with
>> setuid a true and the error is the same. The jobs start but the
>> owner is the property of this script.
>>
>> Also I review all the setuid of file rsh,rlogin and rshd and all is
>> with rws permission.
>
> I just checked on a cluster with 6.0u7 installed: the suid is honored
> like in 6.2 (as it should be IMO). I see no difference - at least
> under Linux. According to your output you are on a different OS?
>
> -- Reuti
>
>
>> Thanks , for you help. Juanma.
>>
>>
>> ----- Original Message -----
>> From: "reuti" <reuti at staff.uni-marburg.de>
>> To: users at gridengine.sunsource.net
>> Sent: Thursday, November 6, 2008 2:21:57 PM GMT +01:00 Amsterdam /
>> Berlin / Bern / Rome / Stockholm / Vienna
>> Subject: Re: [GE users] Grid 6.2 and script with sticky bit on
>>
>> Hi Juanma,
>>
>> Am 06.11.2008 um 11:49 schrieb Juan Manuel Sanchez:
>>
>>> Hi Reuti:
>>>
>>> I was wrong , I was thinking in other issue , our problem is in
>>> script with user set-ID on for example if the script have this
>>> permission:
>>>
>>> -rws--x--x   1 user1  group      20 Nov  5 15:42 test*
>>>
>>> If this script is started by user : user2 ,in version 6.2 the job
>>> is owner of: user1 but in other version 6.0 u07 the job is owner of
>>> user: user2 .
>>>
>>> Is it posible any change in this version?.
>>
>> when the suid is set, it should behave so. Was the former
>> installation mounting the directory with nosuid perhaps?
>>
>> -- Reuti
>>
>>
>>>
>>> ----- Original Message -----
>>> From: "reuti" <reuti at staff.uni-marburg.de>
>>> To: users at gridengine.sunsource.net
>>> Sent: Thursday, November 6, 2008 11:33:07 AM GMT +01:00 Amsterdam /
>>> Berlin / Bern / Rome / Stockholm / Vienna
>>> Subject: Re: [GE users] Grid 6.2 and script with sticky bit on
>>>
>>> Hi Juanma,
>>>
>>> Am 06.11.2008 um 10:34 schrieb Juan Manuel Sanchez:
>>>
>>>> Hi All:
>>>>
>>>> In this version 6.2 if it launch script with sticky bit on the
>>>> owner of this job is the script ownership but in other version 6.0
>>>> u7 , there isn't this problem. The owner job is the user logon and
>>>> not the user owner script with sticky bit.
>>>>
>>>> Is there any change in this new version?. Is there any modify in
>>>> sge_params or execd_params?.
>>>
>>> can you please post an example of this behavior to show what you  
>>> mean
>>> in detail. The sticky-bit is used for directories to disallow file
>>> deletion inside it by someone else than the owner. I don't see the
>>> connection to submitted jobs for now.
>>>
>>> -- Reuti
>>>
>>>
>>>> Best Regards Juanma.
>>>>
>>>> ------------------------------------------------------
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?
>>>> dsForumId=38&dsMessageId=88175
>>>>
>
>>>> To unsubscribe from this discussion, e-mail: [users-
>>>> unsubscribe at gridengine.sunsource.net].
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?
>>> dsForumId=38&dsMessageId=88183
>>>
>>> To unsubscribe from this discussion, e-mail: [users-
>>> unsubscribe at gridengine.sunsource.net].
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?
>>> dsForumId=38&dsMessageId=88187
>>>
>>> To unsubscribe from this discussion, e-mail: [users-
>>> unsubscribe at gridengine.sunsource.net].
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?
>> dsForumId=38&dsMessageId=88206
>>
>> To unsubscribe from this discussion, e-mail: [users-
>> unsubscribe at gridengine.sunsource.net].
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?
>> dsForumId=38&dsMessageId=88212
>>
>> To unsubscribe from this discussion, e-mail: [users-
>> unsubscribe at gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do? 
> dsForumId=38&dsMessageId=88370
>
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe at gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do? 
> dsForumId=38&dsMessageId=88459
>
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe at gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do? 
> dsForumId=38&dsMessageId=88462
>
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe at gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=88464

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=88522

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list