[PVFS2-developers] Re: Limit a particular pvfs2 client's access
rross at mcs.anl.gov
Thu Dec 8 13:48:28 EST 2005
Sam Lang wrote:
>>> I agree with you that this stuff tends to be applied at different
>>> places. I'm not sure that we intended the existing security options to
>>> be global -- we didn't really discuss it. I think both of these things
>>> are really intended to be per file system, even if we don't really
>>> support that level of granularity yet.
>> Yup. I agree with you that they are meant to be per-file-system. I just
>> could not figure out a clean way to get to the f.s stuff from the BMI
>> layer. So it turned out to be a global option. :(
> One way to do this might be to pass in the filesystem_config pointer
> cur_fs instead of the server_config pointer to the BMI_set_info(...
> BMI_TRUSTED_CONNECTION ...) call. That will at least let you call
> get_allowed_ports on the fs_config instead. To get the
> filesystem_config, you just need the fsid (PINT_config_find_fs_id), and
> you should have it at the level from which BMI_set_info is called. If
> you still need to go back and get global security config options
You guys kick this around a little and see what you think, but again I
think we've got bigger fish to fry at the moment.
> As a side note, if we're going to be changing that stuff anyway, does it
> make sense to move the trusted ports/networks stuff one layer up to the
> BMI layer? I feel like putting it just in bmi_tcp is wrong, esp. since
> there's nothing in the Security config options that specifies which bmi
> module to use. It seems like either we should add a required option to
> the Security context that specifies which bmi modules these apply to
> (and its always just tcp for now), other the bmi modules should support
> the trusted ports/networks stuff.
I agree that the current situation isn't quite right. However, so far
we have had no requests for this sort of capability on the other BMI
implementations. So until we decide that we really need client access
control for IB or GM, I say we just keep doing what we're doing.
More information about the PVFS2-developers