Bug 3402 – Running GridFTP in privilege separation mode on non-Linux platforms

Bug 3402 - Running GridFTP in privilege separation mode on non-Linux platforms

Summary:

Running GridFTP in privilege separation mode on non-Linux platforms

Status:	RESOLVED FIXED

Product:	GridFTP
Component:	GridFTP
Version:	4.0.0
Platform:	Macintosh All

Importance:	P3 normal
Target Milestone:	---
Assigned To:	Mike Link

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-05-23 16:13 by Olle Mulmo
Modified:	2005-06-28 17:07 (History)

Attachments
patch to globus_i_gfs_data.c (562 bytes, patch) 2005-05-23 16:14, Olle Mulmo	Details
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From Olle Mulmo 2005-05-23 16:13:48

The attached patch solves a problem for the setuid()/setgid() calls failing on
non-Linux platforms (in my case, Darwin and IRIX): they don't have a check if
current user is root.

I'm not sure the patch is the correct solution to the problem(s), however.

/O

------- Comment #1 From Olle Mulmo 2005-05-23 16:14:26 -------

Created an attachment (id=623) [details]
patch to globus_i_gfs_data.c

------- Comment #2 From Mike Link 2005-05-23 16:26:49 -------

Is the user you're trying to setuid to the same one that the process is running 
as?  It should be, otherwise its just a configuration error.

There are two ways to handle this.  The server sets -auth-mode 0, which will 
disable any gridmap lookup at all and rely on the backends for all 
authorization.  Have a normal gridmap setup on the frontend, with all allowed 
dn's mapped to the frontend user.

If user globus can't setuid to user globus on those platforms, then its 
something that needs to be fixed.

------- Comment #3 From Olle Mulmo 2005-05-24 02:25:51 -------

Aaaaah... I got it now. But... ;-)

Setting auth-level 0 on the frontend means NO AuthZ checking at all.
Communication from any authenticated party will be directly forwarded to the
backend. This makes the whole privilege separation business almost pointless.

Having a separate mapping strategy for the frontend vs. the backend is not
something I would buy into either: keeping a single grid-mapfile in synch with
an everchanging world is hard enough... or in the case of authz callouts, I
would now have to write two versions of it: one that always returns getuid()
instead of the user to map into.

The source of the problem can be found in globus_l_gfs_data_authorize(): it is
not possible to decouple the authz check from the the setuid/setgid calling
logic. This is what my patch tried to fix to a first order of approximation but
it was a hastework. Another solution would be to introduce an explicit
"-[no-]setuid" configuration flag (default: TRUE) or something such.

------- Comment #4 From Mike Link 2005-06-28 17:07:38 -------

4.0.1 will have an additional -auth-level for no setuid.  This should give you 
the result you're looking for.  
Note however that we don't consider -auth-level 0 to be very less secure than 
the normal auth-level on the frontend, since the client would not be able to do 
anything (it wouldn't even get the response back from the user/pass/ sequence) 
until the backend as successfully authorized the user.  The main drawback is 
that authz callouts become impossible with seperated processes when frontend 
has auth-level 0, since the frontend is the side that can make the callouts.