Bugzilla – Bug 3402
Running GridFTP in privilege separation mode on non-Linux platforms
Last modified: 2005-06-28 17:07:38
You need to
before you can comment on or make changes to this bug.
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.
Created an attachment (id=623) [details]
patch to globus_i_gfs_data.c
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.
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.
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.