 |
 |
Hello, I suspect this isn't news to many people but we hit a problem with directories being created with the "wrong" permissions when made with gfal-mkdir via https or davs - they are created 700 rather than the default 755 (which is what you get if you gfal-mkdir root://, and that also respects the -m options to customise the mode). At first I thought this was a bug in either xroot or gfal, however I see the same behaviour if I do a curl MKCOL, and a quick googling suggests there is no equivalent "set mode". So my question is, is this working as expected for the https/davs protocol? Are gfal and xroot both just working within the https/davs limitations/spec? As to why this affects us (asked no one... :-) ), whilst all data is written into our cephfs system by xrootd (and thus owned by that user), the volume is mounted read only on our compute for posix-like read access by other users. Our intention is to allow access via extended ACLs, which work fine if new directories aren't created with 700 permissions (which are also have a strict umask of "---", nerfing our ACLs). For our current workaround, inspired by posts in [1], is for a colleague of mine to create a script that takes ofs.notify mkdir events and reapplies the ACLs. It seems to work, but we have no put it in production (that's Monday's job). The issue also suggests that upcoming xrootd features could provide a workaround for our issue. Thanks all, and have a good weekend, Matt [1]https://github.com/xrootd/xrootd/issues/649 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1