[ARVADOS] updated: 2.1.0-301-ga847c48ed

[Git user]

Summary of changes:
 doc/admin/user-management-cli.html.textile.liquid | 4 ++--
 doc/api/permission-model.html.textile.liquid      | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

  discards  855f6640159c884be776922625a45aeee8f88b10 (commit)
       via  a847c48edba67805cff0104386845be799d74073 (commit)

This update added new revisions after undoing existing revisions.  That is
to say, the old revision is not a strict subset of the new revision.  This
situation occurs when you --force push a change and generate a repository
containing something like this:

 * -- * -- B -- O -- O -- O (855f6640159c884be776922625a45aeee8f88b10)
            \
             N -- N -- N (a847c48edba67805cff0104386845be799d74073)

When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.


commit a847c48edba67805cff0104386845be799d74073
Author: Ward Vandewege <ward at curii.com>
Date:   Fri Jan 29 17:02:57 2021 -0500

    17255: Document the "can_login" permission link in the API section.
    
    Arvados-DCO-1.1-Signed-off-by: Ward Vandewege <ward at curii.com>

diff --git a/doc/admin/user-management-cli.html.textile.liquid b/doc/admin/user-management-cli.html.textile.liquid
index 8cebf02cd..d68529a22 100644
--- a/doc/admin/user-management-cli.html.textile.liquid
+++ b/doc/admin/user-management-cli.html.textile.liquid
@@ -133,9 +133,9 @@ $ ARVADOS_API_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx arv api_c
 
 h2. Adding Permissions
 
-h3. VM login
+h3(#vm-login). VM login
 
-Give @$user_uuid@ permission to log in to @$vm_uuid@ as @$target_username@
+Give @$user_uuid@ permission to log in to @$vm_uuid@ as @$target_username@ and make sure that @$target_username@ is a member of the @docker@ group
 
 <pre>
 user_uuid=xxxxxxxchangeme
@@ -148,7 +148,7 @@ read -rd $'\000' newlink <<EOF; arv link create --link "$newlink"
 "head_uuid":"$vm_uuid",
 "link_class":"permission",
 "name":"can_login",
-"properties":{"username":"$target_username"}
+"properties":{"username":"$target_username", "groups": [ "docker" ]}
 }
 EOF
 </pre>
diff --git a/doc/api/permission-model.html.textile.liquid b/doc/api/permission-model.html.textile.liquid
index 7f1052129..54c4a3331 100644
--- a/doc/api/permission-model.html.textile.liquid
+++ b/doc/api/permission-model.html.textile.liquid
@@ -38,7 +38,7 @@ A permission link is a link object with:
 
 * @owner_uuid@ of the system user.
 * @link_class@ "permission"
-* @name@ one of *can_read*, *can_write* or *can_manage*
+* @name@ one of *can_read*, *can_write*, *can_manage* or *can_login*
 * @head_uuid@ of some Arvados object
 * @tail_uuid@ of a User or Group.  For Group, the @group_class@ must be a "role".
 
@@ -46,6 +46,8 @@ This grants the permission in @name@ for @tail_uuid@ accessing @head_uuid at .
 
 If a User has *can_manage* permission on some object, the user has the ability to read, create, update and delete permission links with @head_uuid@ of the managed object.  In other words, the user has the ability to modify the permission grants on the object.
 
+The *can_login* @name@ is only meaningful on a permission link with with @tail_uuid@ a user UUID and @head_uuid@ a Virtual Machine UUID. A permission link of this type gives the user UUID permission to log into the Virtual Machine UUID. The username for the VM is specified in the @properties@ field. Group membership can be specified that way as well, optionally. See the "VM login section on the CLI cheat sheet":/install/cheat_sheet.html#vm-login for an example.
+
 h3. Transitive permissions
 
 Permissions can be obtained indirectly through nested ownership (*can_manage*) or by following multiple permission links.

-----------------------------------------------------------------------


hooks/post-receive
--