I guess I don' understand how you got yourself in this predicament in the first place unless you are using a setfsuid plugin. That said,
-
We don't support multiple servers writing into he same namespace residing in a distributed file system. The reasons should be obvious as we an't guarantee consistency. We expect people to partition the namespace in some way between the servers to avoid servers clobbering other server's files. So, my guess is that this isn't being done. Yes, it will work most of the time but not all the time.
-
We don't recommend using nobody for the xrootd userid since the xrootd must be able to control it's own files. Of course, if you are using setfsuid and the xrootd has setfsuid capabilities then it would work but not in the POSC case without some additional work (note we don't support setfsuid, well not yet). If you use sefsuid then you certainly know who owns the file to be deleted and could assume that identity in order to unlink the file. As you note, the code is not there to do that because because there is no native support for setfsuid.
Failing initialization when a POSC file cannot be deleted is he correct response in order to guarantee "poscness".
I would not give xrootd root privileges. Even if you did you would have to change the start-up options and the code would work anyway as it reverts to a non-root uid when it starts running. Passing a fake security object wouldn't work also as the clean-up happens during initialization and there is no reference to a security object that point (xrootd assumes it can cleanup files it created notwithstanding a setfsuid plugin).
Here are some options (assuming I understand what is going on here):
a) If a setfsuid is being used, the plugin should check if the file will be created using POSC. If so, the file's ownership needs to belong to xrootd until a successful close occurs. At that point the ownership can be changed. Of course, that introduces a small window where the server may crash and the files ownership is wrong.
b) If he file systems supports ACL's that set the ACL to allow the normal xrootd userid full privileges. This is only workable if ACL's are recursive in nature.
c) Run an external program prior to start-up or launch one before POSC cleanup is invoked to do the actual cleanup. While that makes you dependent on he current implementation, at least it's isolated to one external program.
If you give me details on how this situation occurs n the first place, perhaps I can provide additional suggestions.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/xrootd/xrootd","title":"xrootd/xrootd","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/xrootd/xrootd"}},"updates":{"snippets":[{"icon":"PERSON","message":"@abh3 in #830: I guess I don' understand how you got yourself in this predicament in the first place unless you are using a setfsuid plugin. That said,\r\n\r\n1) We don't support multiple servers writing into he same namespace residing in a distributed file system. The reasons should be obvious as we an't guarantee consistency. We expect people to partition the namespace in some way between the servers to avoid servers clobbering other server's files. So, my guess is that this isn't being done. Yes, it will work most of the time but not all the time.\r\n\r\n2) We don't recommend using nobody for the xrootd userid since the xrootd must be able to control it's own files. Of course, if you are using setfsuid and the xrootd has setfsuid capabilities then it would work but not in the POSC case without some additional work (note we don't support setfsuid, well not yet). If you use sefsuid then you certainly know who owns the file to be deleted and could assume that identity in order to unlink the file. As you note, the code is not there to do that because because there is no native support for setfsuid.\r\n\r\nFailing initialization when a POSC file cannot be deleted is he correct response in order to guarantee \"poscness\".\r\n\r\nI would not give xrootd root privileges. Even if you did you would have to change the start-up options and the code would work anyway as it reverts to a non-root uid when it starts running. Passing a fake security object wouldn't work also as the clean-up happens during initialization and there is no reference to a security object that point (xrootd assumes it can cleanup files it created notwithstanding a setfsuid plugin).\r\n\r\nHere are some options (assuming I understand what is going on here):\r\na) If a setfsuid is being used, the plugin should check if the file will be created using POSC. If so, the file's ownership needs to belong to xrootd until a successful close occurs. At that point the ownership can be changed. Of course, that introduces a small window where the server may crash and the files ownership is wrong.\r\nb) If he file systems supports ACL's that set the ACL to allow the normal xrootd userid full privileges. This is only workable if ACL's are recursive in nature.\r\nc) Run an external program prior to start-up or launch one before POSC cleanup is invoked to do the actual cleanup. While that makes you dependent on he current implementation, at least it's isolated to one external program.\r\n\r\nIf you give me details on how this situation occurs n the first place, perhaps I can provide additional suggestions."}],"action":{"name":"View Issue","url":"https://github.com/xrootd/xrootd/issues/830#issuecomment-424950804"}}}
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/xrootd/xrootd/issues/830#issuecomment-424950804",
"url": "https://github.com/xrootd/xrootd/issues/830#issuecomment-424950804",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [xrootd/xrootd] POSC doesn't work well with XrdOss plugins (#830)",
"sections": [
{
"text": "",
"activityTitle": "**Andrew Hanushevsky**",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": "@abh3",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"xrootd/xrootd\",\n\"issueId\": 830,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\": \"xrootd/xrootd\",\n\"issueId\": 830\n}"
},
{
"targets": [
{
"os": "default",
"uri": "https://github.com/xrootd/xrootd/issues/830#issuecomment-424950804"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 384632063\n}"
}
],
"themeColor": "26292E"
}
]
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
