Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #12160 (closed)

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

Bug: remove user_userid FS restriction

Reported by: jamoore Owned by: mtbcarroll
Priority: blocker Milestone: 5.0.2
Component: OmeroFs Version: 5.0.0
Keywords: n.a. Cc: fs@…, dnmason@…, pierre.pouchin@…
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: 0.0d
Sprint: n.a.

Description

See: https://www.openmicroscopy.org/community/viewtopic.php?f=4&t=7485&p=13803#p13803

As of 5.0.0, it's not possible to put groupId or similar at the top of the omero.fs.repo.path configuration value. This would simplify reporting considerably.

At the same time, we should review if there are any impacts from moving from one scheme to the next.

Change History (14)

comment:1 Changed 10 years ago by cblackburn

Would it be sufficient to simply have a restriction that required user and/or user_id to appear at some point in the template?

comment:2 Changed 10 years ago by jamoore

With the possible stipulation, that all the directories up to the first with user_id (which is the real requirement, since user name can change) will have to be made public.

comment:3 Changed 10 years ago by mtbcarroll

In http://www.openmicroscopy.org/community/viewtopic.php?f=5&t=7430&p=13870 it is said,

The problem I see is that omero users come from LDAP, but their IDs are appended to their names in the managed repository which makes it hard to map them to a restricted share.

comment:4 Changed 10 years ago by jamoore

  • Cc pierre.pouchin@… added

comment:5 Changed 10 years ago by jamoore

The major difficulty it appears is that the first user to create a directory owns it.

  • bin/omero config set omero.fs.repo.path %groupId%/%userId%/%year%-%month%/%day%/%time%
  • bin/omero group add test_group # Below 1203
  • bin/omero user add test_user Test User test_group # Below 1202
  • touch test.fake
  • bin/omero import test.fake
  • Now, /OMERO/ManagedRepository/1203 belongs to user 1202:
 id  | owner_id | group_id |                path                 |         name          
-----+----------+----------+-------------------------------------+-----------------------
 207 |     1202 |     1203 | 1203/1202/2014-04/25/22-30-37.925/  | test.fake
 206 |     1202 |     1203 | 1203/1202/2014-04/25/               | 22-30-37.925.log
 205 |     1202 |        1 | 1203/1202/2014-04/25/               | 22-30-37.925
 204 |     1202 |        1 | 1203/1202/2014-04/                  | 25
 203 |     1202 |        1 | 1203/1202/                          | 2014-04
 202 |     1202 |        1 | 1203/                               | 1202
 201 |     1202 |        1 | /                                   | 1203

The options I can think of are:

  • give all directories before the first instance of %userId% to root (uid=0).
  • give all directories to root.
  • provide either/or-semantics: the top-level contains *either* %userId% *or* %groupId (in the latter case, it'll belong to root)
  • if another user requests a path after the fact, *then* give it to root

The primary difficult with giving the directories to root is that they won't be deletable by regular users. A group admin, however, should be able to get rid of them.

comment:6 Changed 10 years ago by mtbcarroll

  • Owner changed from jamoore to mtbcarroll

So jamoore has experimented with https://github.com/joshmoore/openmicroscopy/commit/c465bff2 and there is an idea to specify two template paths: a "first half" which may not contain %user% or %userId% and whose directories root would own, and a "second half" specifying directories below that, to be owned by the user. Of the allowable elements,

# %user%       bob
# %userId%     4
# %group%      bobLab
# %groupId%    3
# %year%       2011
# %month%      01
# %monthname%  january
# %day%        01
# %time%       15-13-54.014

what rules should there be besides %user% and %userId% not appearing in the first part and %time% appearing somewhere (for uniqueness)?

comment:7 Changed 10 years ago by jamoore

By first part I understand the, "shared template path" which will belong to root, and the "second half" is the current regular template path which belongs to the user. I'm not sure any of the loose rules you mention need to hold: if we have this separation, then *I think* you can put anything anywhere. Sysadmin may want %user_id% in the global part. A user may want %group_id% in the user part. Splitting hopefully frees us from worrying about it.

comment:8 Changed 10 years ago by mtbcarroll

  • Status changed from new to accepted

comment:9 Changed 10 years ago by mtbcarroll

To mark first part with root, in the Current.ctx can inject root's String rootUuid value for the omero.constants.SESSIONUUID.value key, and then something like repoDao.makeDirs(this, paths, sudo(current, rootUuid)) with sudo in PublicRepositoryI. See AdminImpl doing SecuritySystem.runAsAdmin().

comment:10 Changed 10 years ago by mtbcarroll

I can get rid of the "User-directory name mismatch!"-detecting code block but then we run into RepositoryDaoImpl.canWriteParentDirectory's "No annotate access for parent directory": any thoughts?

comment:11 Changed 10 years ago by jamoore

The theory behind canWPD() was a way to guarantee that users don't create directories in any ole' place. We should be able to define something clear enough (parent directory is in user group, etc) to make this still secure.

comment:12 Changed 10 years ago by mtbcarroll

The parent directory will be root's? But maybe we can get a "if we're in the managed repository" condition in there.

Update: ohh, maybe I see what you mean: perhaps normal root directories are in the system group or something and we can create the managed repository root-owned directories to be in the user group. Perhaps that means an appropriate omero.group or something in the context when those directories are made. We can talk on Monday.

Last edited 10 years ago by mtbcarroll (previous) (diff)

comment:13 Changed 10 years ago by mtbcarroll

  • Resolution set to fixed
  • Status changed from accepted to closed

comment:14 Changed 10 years ago by Josh Moore <josh@…>

  • Remaining Time set to 0

(In [48bb104f08047c2d4f28740c1734d1de6b570b58/ome.git] on branch develop) Merge pull request #2514 from mtbc/rebased/develop/trac-12160-template-paths

fix #12160: root-owned template paths (rebased from dev_5_0)

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.66466 sec.)

We're Hiring!