 |
 |
Hi Andy, so when starting xrootd you specify the file space to be exported and then you can only open files via full pathnames into that file space. Correct? Cheers, Fons. On Wed, 2004-08-18 at 22:52, [log in to unmask] wrote: > 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 > > ------------------------------------------------------------------------- > > -- Org: CERN, European Laboratory for Particle Physics. Mail: 1211 Geneve 23, Switzerland E-Mail: [log in to unmask] Phone: +41 22 7679248 WWW: http://www.rademakers.org/fons/ Fax: +41 22 7679480