 |
 |
Hi Doug, comments below: regards, Wei Yang | [log in to unmask] | 650-926-3338(O) On Apr 29, 2011, at 10:27 AM, Doug Benjamin wrote: > Hello, > > I have been looking at the xrootd documentation (yes, Andy I really do read it) > on security. Right now our cluster (an others who use our example) are using > unix security (yes I know that - > > "Warning: unix protocol does not provide any significant level of security > and should only be used in instances where security violations do not matter." > > Can I have only one security protocol defined for each data server? > Are the following lines valid in the server section of the config file: > > sec.protocol /usr/lib64 unix > sec.protocol /usr/lib64 sss You may want to put sss ahead of unix because xrootdfs can use both. If you put unix first, xrootdfs will happily pickup unix security (I think I verified this a while ago). > We would like to use security for xrootdfs so that they follow the same > security model as the using xrootd clients (like those in root or xrdcp). > > > > From the xrootdfs readme file in the git repository the security section > has the lines: > > > >Security: > >======== > > > >Without enabling Xrootd security module, Xrootd data servers map all XrootdFS > >users from a given XrootdFS instance to the user that actually runs that XrootdFS > >instance. With Xrootd's security module "sss" enabled in both Xrootd data server > >and XrootdFS, XrootdFS will provide to the Xrootd data servers the actual user > >information for access control. > > Does this mean that when xrootdfs process makes a connection to the datasever > the user name of the person using the xrootdfs command (not the daemon running > the xrootdfs process) is passed to the data server. In this way > the authorization file specified by acc.authdb /etc/xrootd/auth_file > is followed? I am assuming yes, but have not tested it yet. I guess yes:-) Let me clarify: the identity of the user using ls/cp/rm against files in xrootdfs will be passed to data server. > My next question is about the ownership of the client's keytable. > > I understand that in configuration of the data server I can make this declaration > > sec.protocol /usr/lib64 sss -c /etc/xrootd/.xrd/ > sss.keytab.grp -s /etc/xrootd/.xrd/sss.keytab > .grp > > On the data server machines the file must be owned by the same process who is running the > data servers. On the client machines the situation is a bit more complex. If I want > xrootdfs running as when as user client jobs, then can I have the keytab file owned by > the process running xrootdfs and the group permission being a group common to all of > the users? The key file to get xrootdfs and data server to work together is a little special. Users don't need to access the key file. The xrootdfs daemon will access this key file, and because the key file is "a little special", it allows xrootdfs to assume users identity when talking to data servers. If you can dig out my e-mail on Feb 18, 2011, it has the instruction (or I can resend to you). > Thanks in advance for your help. > > Cheers, > > Doug Benjamin >