Results 1 to 6 of 6

Thread: [SOLVED] undocumented (?) zmmailbox permission argument

  1. #1
    Join Date
    Jun 2008
    Berkeley, CA
    Rep Power

    Default [SOLVED] undocumented (?) zmmailbox permission argument

    In the CLI, I can do

    zmmailbox -z -m <accountname>

    to open an interactive session on <accountname>. I then do

    help permissions

    and among the commands that appear is

    grantPermission(grp) {account {name}|group {name}|key {name} [{access key}]|all|public {[-]right}}

    What I want to know about is the key {name} [{access key}] argument. I can't find any documentation for how this is used and what it does. Any help?

  2. #2
    Join Date
    Jul 2007
    Rep Power


    i don't think he's looking for the permission list, but rather what the key stuff is for. is that what is used when you choose to share a folder with an external guest through the UI?

  3. #3
    Join Date
    Nov 2006
    Rep Power


    Yes I believe it is.

  4. #4
    Join Date
    Jun 2008
    Berkeley, CA
    Rep Power


    That would be strange since the lp command within zmmailbox only lists invite, loginAs, and viewFreeBusy as permission types that are controlled by grp, and those don't seem to related to the UI sharing interface's options.
    Last edited by ewilen; 02-19-2009 at 06:17 AM.

  5. #5
    Join Date
    Jun 2008
    Berkeley, CA
    Rep Power


    I hate to bump, but it's been a week. Anyone?

  6. #6
    Join Date
    May 2006
    Rep Power


    Here's the rundown (info on keys is at the bottom but humor the edumacation/for others coming along):

    Standard Permissions (grp):
    grantPermission(grp) {account {name}|group {name}|key {name} [{access key}]|all|public {[-]right}}
    Remove with revokePermission(rvp).
    Show with getPermission(gp).

    invite and viewFreeBusy are exposed in the UI: Bug 22913 - Access control for free busy and resources / permission to invite see ZimbraServer/docs/accesscontrol.txt & preferences > calendar tab in 5.0.7+

    loginAs was added in 5.0.9+ for IMAP Bug 30051 - GSSAPI: support additional mailbox access using kerberos the title may be misleading, but it actually added an ACL:
    In 5.0.9, as part of bug 30051, we will add an enhancement with an account level zimbraACE (access control entry) called "loginAs" and necessary IMAP code path changes to honor this ACE. Zimbra web UI will not be updated to reflect this permission in 5.0.9 - that will come in a later release, for now only IMAP/POP3 login will honor this. This "loginAs" support IMAP will also work for SASL PLAIN in addition to kerberos/GSSAPI.
    Web client RFE: Bug 35134 - Add login As functionality to the web client

    Shared folders on the other hand are normally done with mfg & cm:
    modifyFolderGrant(mfg) {folder-path} {account {name}|group {name}|domain {name}|all|public|guest {email} [{password}]|key {email} [{accesskey}] {permissions|none}}
    Where permissions are:
    (r)ead - search, view overviews and items
    (w)rite - edit drafts/contacts/notes, set flags (i)nsert - copy/add to directory, create subfolders action
    (x) - workflow actions, like accepting appointments
    (d)elete - delete items and subfolders, set \Deleted flag
    (a)dminister - delegate admin and change permissions

    zmmailbox -z -m modifyFolderGrant /Folder account rwx

    createMountpoint(cm) [opts] {folder-name} {owner-id-or-name} {remote-item-id-or-path}
    -F/--flags <arg> flags
    -c/--color <arg> color
    -V/--view <arg> default type for folder (appointment,contact,conversation,document,message ,task,wiki)
    zmmailbox z -m createMountpoint --view appointment "/Vacation Calendar" /VacationDates

    Remove the mount with deleteFolder(df)not on the original account though - and remove the permission with modifyFolderGrant none.
    List by getFolderGrant(gfg).

    You can share the root / on an account see bug 26465 & there's an RFE Bug 24804 – Share entire mailbox in one click.

    Or if you prefer there's family mailboxes: Mailboxes: Sharing vs. Relationships &#187; Zimbra :: Blog
    Quote Originally Posted by bdial View Post
    is that what is used [keys] when you choose to share a folder with an external guest through the UI?
    Keys are different than guest email/password (which is currently exposed in the share dialog):

    Now keys, think of these as tokens: A User can reset/remove the key and the previous web link url is no longer valid.

    For instance if you change your ZCS password, and an external site using your feeds (ics, rss) keeps retrying with old password, your account will get locked out. Both guest & keys solve this issue, keys have the advantage of being random. Plus for keys you don't always have to specify a email address (or a like you could do with guest), so you can generate one for your own usage if you want. And lastly you can auth without a user:loginpass argument to a URL, just path with token on the end. Remember some applications out there that can't do auth arguments in the url like browsers do.

    Some server ACL/SOAP/REST work was done in Bug 30049 - YCC URL token for folders for ZCS & YCC UI. (They're in the new Yahoo Calendar.)

    So when using grantPermission and modifyFolderGrant zmmailboxcommands, if your setting the grantee to key, specifiy a email/user/id and accesskey. If 'accesskey' is not specified, server will generate 128-bit secure random value and store hex ascii string version of it. (example: 547aec8da28d47d3ecfaa75000056e3d)

    So walkthrough of the commands:
    zmmailbox -z -m mfg /Calendar key 12345678-1234-1234-1234-123456789123 r
    (You don't have to make it that long.)

    How can you see it if you dont' set it? Well apparently they're exposed in normal soap but not zmmailbox:
    zmmailbox -z -m gfg /Calendar
    Permissions Type Display
    ----------- ------ -------
    r key
    We need a way to return the "key" to the front-end when it is displaying the links in the folder sharing screen, but we probably don't want to return the "key" in normal <refresh> blocks (i.e., on every login). Does this mean we should only return them on explicit GetFolderRequest calls and/or add a new soap call to access them?
    expose accesskey only in response for explicit GetFolderRequest, *not* in normal <refresh> blocks
    They don't show in zmmailbox getFolder either:
    zmmailbox -z -m gf /Calendar{
    "color": "defaultColor",
    "contentSequence": 1,
    "defaultView": "appointment",
    "flags": "#i",
    "grants": [{
    "id": "",
    "permissions": "r",
    "type": "key"
    "id": "10",
    "isCheckedInUI": true,
    "i***cludedFromFreeBusy": false,
    "isSyncEnabled": false,
    "isSyncFolder": false,
    "isSystemFolder": true,
    "itemCount": 0,
    "name": "Calendar",
    "parentId": "1",
    "path": "/Calendar",
    "pathURLEncoded": "/Calendar",
    "size": 0,
    "subFolders": [],
    "unreadCount": 0
    (Kinda think someone should open an RFE to show them in getFolderGrant & getFolder.)

    You have construct some SOAP or use CLI zmsoap:
    zmsoap -z -m -v -e GetFolderRequest/folder path=/Calendar

    Sending admin auth request to https://localhost:7071/service/admin/soap

    <GetFolderRequest xmlns="urn:zimbraMail">

    <GetFolderResponse xmlns="urn:zimbraMail">
    <folder rev="1" l="1" view="appointment" n="0" name="Calendar" id="10" f="#i" s="0">
    <grant gt="key" key="12345678-1234-1234-1234-123456789123" zid="" perm="r"></grant>
    ACLs are persisted in LDAP in the multi-valued "zimbraACE" attribute on the target LDAP entry.
    all has a pseudo id of 00000000-0000-0000-0000-000000000000
    pub has pseudo id of 99999999-9999-9999-9999-999999999999
    and - (minus sign) is deny

    There was some additional discussion on how to store those:
    ACLs are generally associated with a single object in a user's Mailbox, either a folder or a tag. As such, the ACLs should probably be persisted in the user's database; we've always shied away from allowing LDAP entries to refer directly to Mailbox items because of the complexities in keeping the two stores in sync. Also, reducing writes to LDAP is usually advisable because of the limited write throughput on the master.

    In the mailbox, the METADATA column on the MAIL_ITEM row for the folder or tag eems like the right place to serialize ACL data. We automatically load that data when the folders and tags are loaded, so it won't require either extra joins or extra fetches during the folder/tag preload. Those folder and tag objects are kept cached for the lifetime of the Mailbox, so it also won't require subsequent database accesses when checking item
    permissions. And the METADATA contents are automatically deleted when the folder or tag's row is deleted, so cleanup is trivial.
    There's also: Bug 32952 - auto-expiring token keys for folder sharess (time based)

    Exposing that in the UI: Bug 30834 - ZWC URL token for folder access & Bug 20039-Need private/backdoor REST URLs (probable dupe, but needs to explore IMAP URLAUTH=<access>:<mech>:<token> case.)
    Last edited by mmorse; 03-12-2009 at 03:12 PM. Reason: diff between guest & key

Similar Threads

  1. Help!!! Moving ZCS does not work!
    By ASebestian in forum Migration
    Replies: 7
    Last Post: 02-12-2009, 05:06 PM
  2. Problem with Mail Server - Need help!
    By joeleo in forum Installation
    Replies: 2
    Last Post: 03-04-2008, 11:03 AM
  3. Backup issues
    By telescop in forum Administrators
    Replies: 3
    Last Post: 03-01-2007, 05:09 PM
  4. Ldap issues
    By mississippiman in forum Installation
    Replies: 11
    Last Post: 01-09-2007, 07:00 PM
  5. Move server to different OS
    By EriSan500 in forum Administrators
    Replies: 7
    Last Post: 03-05-2006, 12:00 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts