 |
 |
Hi Fons, Yes, the security heads here are rather strict. No default should expose any data is the general rule. So, the only thing left to export is /tmp. As Pete pointed out, you can simply specify the path on the command line. If you want to export your home directory, then saying "xrootd ~" is sufficent (the shell expands the tilde). In general, no relative paths are allowed. Xrootd even prohibits clients from using relative paths to access data. Historically, that proved to be the easiest way of getting to data that you weren't supposed to get to. Andy ----- Original Message ----- From: "Peter Elmer" <[log in to unmask]> To: "Fons Rademakers" <[log in to unmask]> Cc: <[log in to unmask]>; <[log in to unmask]>; <[log in to unmask]>; "Alvise Dorigo" <[log in to unmask]>; "Fulvio Galeazzi" <[log in to unmask]>; "Andrew Hanushevsky" <[log in to unmask]>; "Jean-Yves Nief" <[log in to unmask]>; "Akram Khan" <[log in to unmask]>; "Guglielmo De Nardo" <[log in to unmask]>; "Gerardo Ganis" <[log in to unmask]> Sent: Wednesday, August 18, 2004 5:39 AM Subject: Re: xrootd meeting - Tuesday, 17 August, 2004 > On Wed, Aug 18, 2004 at 02:25:49PM +0200, Fons Rademakers wrote: > > Yes, I get an error message from TXUrl. Gerri can you maybe check this > > and fix it so that localhost works again in the rootd url? > > > > Other question, how do I start xrootd so that is assumes relative paths > > to start in the users home directory? Now default is /tmp. > > Which user? The one which started xrootd or the one accessing files? > > xrootd behaves differently that rootd in this respect. It doesn't assume > that paths start in /tmp by default, it only allows access to /tmp by default. > I've recently started to add some example configurations to describe some > things: > > http://xrootd.slac.stanford.edu/examples/ > > but the short answer is that you can export other area (e.g. like /data) with > either a line in the config file: > > xrootd.export /data > > or by starting xrootd as: > > xrootd /data > > I don't think it takes a "*" (obviously very insecure). > > There is a separate option "oss.localroot" which allows for a _global_ > server side prefix to all paths, i.e. a file at /mnt/temp/path/myfile.root > with: > > oss.localroot /mnt/temp > > will be accessed as > > root://host:port//path/myfile.root > > I'm not actually surt how it will behave for relative paths: > > root://host:port/myfile.root * > > or for > > root://host:port/~elmer/myfile.root > root://host:port/~/myfile.root * > > This is what you are asking about, is that correct? Could you remind me > exactly what is done by rootd in the two cases marked with an "*"? (i.e. > relative path WRT what and "~" means which user?) > > Pete > > > > > On Wed, 2004-08-18 at 11:24, Peter Elmer wrote: > > > Hi Fons, > > > > > > On Tue, Aug 17, 2004 at 12:48:43PM +0200, Fons Rademakers wrote: > > > > the rule in TFile::Open for opening via rootd currently is: > > > > > > > > "If the url points to the localhost and the file will be opened in > > > > readonly mode and the current user has read access or the specified > > > > user is equal to the current user then open local TFile." > > > > > > > > This feature is specially important for PROOF where we access files > > > > always via rootd urls (so any worker can access any file) but where the > > > > packetizer optimizes the work so that the workers mostly will get local > > > > files. Using the above feature these local files will be opened directly > > > > as TFile's and won't go through rootd. To force a local file to be > > > > opened via rootd specify as host "localhost". If TXUrl this also > > > > supports then we will have the same behavior. If this "localhost" > > > > feature is supported by netx/xrootd then we can always use that as > > > > "backdoor" to test xrootd on the same machine as where the client runs. > > > > > > Yes, the "localhost" option was in fact what Alvise and Fabrizio were > > > using themselves for this purpose. I've still not succeeded in building > > > the HEAD, but is the issue you are seeing related to the "in or out domain" > > > checks? That is what I was seeing with the last XTNetFile version before > > > they began the migration to TXNetFile. > > > ------------------------------------------------------------------------- > Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) 767-4644 > Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland > ------------------------------------------------------------------------- >