JIRA Issue

[#XCI-133] Several Globus sharing improvements

[XCI-133] Several Globus sharing improvements Created: 06/06/2017  Updated: 07/12/2018

Status: Proposed
Project: XSEDE Cyberinfrastructure Integration
Component/s: Globus Toolkit GridFTP Service
Fix Version/s: None

Type: XCI Engineering Analysis Priority: Major
Reporter: Shava Smallen Assignee: Lee Liming
Resolution: Unresolved Votes: 0

XSEDE Priority: -
Public activity link: https://software.xsede.org/display/xci-133
Devel Repository:
Use Cases:
CAN-02: Managed data transfer
Effort and Costs:
Staff Name (Lastname, Firstname) Effort (person weeks) Roles or Contributions Status
<Activity Lead Name – Last, First> 6 six weeks of effort to lead and implement the activity (required) none
<User Doc Drafter – Last, First> 0.2 one day of effort to draft user documentation (required ) none
TBD (tester) 1 one week of effort to test the software none
... ... .. none
Due by Activity Deliverable
((DSR TRR Deployment)) ((Deliverable name))
DSR Design document*
TRR Implemented Software Capability
TRR Other type of deliverable
TRR Deployment plan*
TRR Test plan*
TRR User documentation*
TRR (post) TRR Baseline* (Shava)
Deployment Deployment Baseline* (Shava)
Deployment Test Report* (Shava)
  • Click on "Deliverables" tab for URL.
Lead Tester: Shava Smallen


From Scott Sakai at SDSC. Lee, could you please check into the status of these with the Globus team and see if we need to prepare a new release of GridFTP?

There were several patches supplied to Globus. Some of them were accepted,
like making sure the user has an executable shell. The rest were not
accepted with no reason why.

XSEDE may have received a copy as well, but I haven't been pushing for its

Here's the remainder that we apply:

  • Share restrict paths matching changes matching behavior from "first match
    wins" to "longest match (by normalized path component) wins". This stops
    the sharing_rp directive from having different results depending on how the
    elements are ordered.

given sharing_rp: RW/share/$USER/shared,N/
orig : User can use /share/$USER/shared (expected)
patch: User can use /share/$USER/shared (expected)

given sharing_rp: N/,RW/share/$USER/shared
orig : User can't use /share/$USER/shared (unexpected)
patch: User can use /share/$USER/shared (expected)

  • The wildcard * expands to a single level of directory path components in
    sharing_rp, instead of any number.
    given sharing_rp: RW/share/projects/*/$USER/shared-data,N/

orig: User1 in project 1 can use
/share/projects/project1/user1/shared-data (expected)
orig: User1 not in project 2 can use
/share/projects/project2/stuff/more-stuff/user1/shared-data (unexpected)

patch: User1 in project 1 can use
/share/projects/project1/user1/shared-data (expected)
patch: User1 not in project 2 can't use
/share/projects/project2/stuff/more-stuff/user1/shared-data (expected)

  • Disable the ability to accidentally allow disabled accounts. If we
    disable an account, it's with the expectation that it won't be used by any
    service, including gridftp.

given: locked Unix account for user2, allow_disabled_login = true
orig : user2 can use sharing/gridftp (unexpected)
patch: user2 cannot use sharing/gridftp

  • Sharing state files can be owned by root. Maybe we'll want to make sure
    a user doesn't tamper with their share later.

orig : Share files need to be owned by the share's administrator
patch: Share files need to be owned by the share's administrator or root

  • Additional sanity checks applied to sharing state directories.
  • If sharing state dir is owned by share's administrator, it must not
    have group- or world- read, write, or execute permissions. (prevents
    tampering or exposure of secrets in sharing state files)
  • If sharing state dir is owned by root and is group- or world- writable,
    it must have the sticky bit set. (prevents tampering with sharing state files)
  • All other ownership / permission combinations for sharing state dir
    constitute a configuration error. (Prevents tampering with share state
    files or inadvertently placing share state files in the hands of an
    unprivileged user.)