LISTSERV 16.5 - XROOTD-DEV Archives

I don't see how this could work. Consider this stack:

(gdb) bt
#0  XrdCksManOss::Calc (this=0x2416db0, Lfn=0x7f5c7c00b0a0 "/tmp/xrootd/fooGoogle", Cks=..., 
    doSet=1) at /home/cse496/bbockelm/projects/xrootd/src/XrdCks/XrdCksManOss.cc:101
#1  0x00007f5cbae9221e in XrdOfs::chksum (
    this=0x7f5cbb133a80 <XrdSfsGetDefaultFileSystem(XrdSfsFileSystem*, XrdSysLogger*, char const*, XrdOucEnv*)::XrdDefaultOfsFS>, Func=XrdSfsFileSystem::csCalc, 
    csName=0x7f5c7c00b2d0 "md5", Path=0x7f5c7c00b0a0 "/tmp/xrootd/fooGoogle", einfo=..., 
    client=0x0, opaque=0x0) at /home/cse496/bbockelm/projects/xrootd/src/XrdOfs/XrdOfs.cc:1568
#2  0x00007f5cb1bf43be in MultiuserFileSystem::chksum (this=0x23ba680, 
    Func=XrdSfsFileSystem::csCalc, csName=0x7f5c7c00b2d0 "md5", 
    path=0x7f5c7c00b0a0 "/tmp/xrootd/fooGoogle", eInfo=..., client=0x0, opaque=0x0)
    at /home/cse496/bbockelm/projects/xrootd-multiuser/src/multiuser.cpp:566
#3  0x00007f5cbae6ede0 in XrdXrootdProtocol::CheckSum (Stream=0x7f5c7c00c010, 
    argv=0x7f5caa2389e0, argc=4)
    at /home/cse496/bbockelm/projects/xrootd/src/XrdXrootd/XrdXrootdProtocol.cc:890
#4  0x00007f5cbab48cf7 in XrdOucProg::Run (this=0x23b9e50, Sp=0x7f5c7c00c010, 
    argV=0x7f5caa238c70, argC=3, envV=0x0)
    at /home/cse496/bbockelm/projects/xrootd/src/XrdOuc/XrdOucProg.cc:140
#5  0x00007f5cbab48f20 in XrdOucProg::Run (this=0x23b9e50, Sp=0x7f5c7c00c010, 
    arg1=0x7f5c7c00b2d0 "md5", arg2=0x7f5c7c00b0a0 "/tmp/xrootd/fooGoogle", 
    arg3=0x7f5c7c00bb80 "bbockelm.8:34@localhost", arg4=0x0)
    at /home/cse496/bbockelm/projects/xrootd/src/XrdOuc/XrdOucProg.cc:173
#6  0x00007f5cbae64a5e in XrdXrootdJob2Do::DoIt (this=0x7f5c7c00bf60)
    at /home/cse496/bbockelm/projects/xrootd/src/XrdXrootd/XrdXrootdJob.cc:168
#7  0x00007f5cbab88bf0 in XrdScheduler::Run (this=0x61bde0 <XrdGlobal::Sched>)
    at /home/cse496/bbockelm/projects/xrootd/src/Xrd/XrdScheduler.cc:382
#8  0x00007f5cbab87d24 in XrdStartWorking (carg=0x61bde0 <XrdGlobal::Sched>)
    at /home/cse496/bbockelm/projects/xrootd/src/Xrd/XrdScheduler.cc:88
#9  0x00007f5cbab2e886 in XrdSysThread_Xeq (myargs=0x7f5c9c001470)
    at /home/cse496/bbockelm/projects/xrootd/src/XrdSys/XrdSysPthread.cc:86
#10 0x00007f5cba6abdd5 in start_thread (arg=0x7f5caa239700) at pthread_create.c:307
#11 0x00007f5cb99adead in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

The checksum is run as a standalone XrdXrootdJob and only gets 4 parameters in addition to the XrdOucStream object. The function XrdXrootdProtocol::CheckSum does not have access to the XrdSecEntity associated with the operation. Hence, by time XrdOfs::chksum is invoked, there's no XrdSecEntity there either. We can now pass down the pointer through the interface you changed - but it's still nullptr.

I looked into what it'd take to make the XrdXrootdJob infrastructure credential-aware but it's not clear what lifetime guarantees need to be made.

Can you take a look at this please?

There's still a small amount of other changes needed to pass the pointer down the stack; I'll submit those in a bit. It's just that, again, we're currently passing down a nullptr.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/issues/1294#issuecomment-720506600", "url": "https://github.com/xrootd/xrootd/issues/1294#issuecomment-720506600", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1