Task #12160 (closed)
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
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.
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)
Would it be sufficient to simply have a restriction that required user and/or user_id to appear at some point in the template?