Imported Upstream version 1.3upstream/1.3

3 files changed, 111 insertions, 51 deletions

diff --git a/docs/design-acl b/docs/design-acl
index 424b3c6..836c411 100644
--- a/docs/design-acl
+++ b/docs/design-acl
@@ -13,7 +13,7 @@ Introduction
 Syntax
 
     An ACL entry in the wallet consists of two pieces of data, a <scheme>
-    and an <instance>. <scheme> is one or more characters in the set
+    and an <identifier>. <scheme> is one or more characters in the set
     [a-z0-9-] that identifies the ACL backend to use when interpreting
     this ACL.  <identifier> is zero or more characters including all
     printable ASCII characters except whitespace.  Only the implementation
@@ -31,9 +31,10 @@ Semantics
     used:  Iterate through each ACL entry in the ACL in question.  If the
     ACL entry is malformatted or the scheme is not recognized, skip it.
     Otherwise, dispatch the question to the check function of the ACL
-    implementation, passing it the principal identifying the client and
-    the <identifier> portion of the ACL entry.  This function returns
-    either authorized or unauthorized.  If authorized, end the search; if
+    implementation, passing it the principal identifying the client, the
+    <identifier> portion of the ACL entry, and the type and name of the
+    object the user is attempting to access.  This function returns either
+    authorized or unauthorized.  If authorized, end the search; if
     unauthorized, continue to the next ACL entry.
 
     There is no support in this scheme for negative ACLs.
@@ -50,11 +51,35 @@ Semantics
 
 ACL Schemes
 
+  external
+
+    The <identifier> is arguments to an external command.  Access is
+    granted if the external command returns success.  The standard remctl
+    environment variables are exposed to the external command.
+
   krb5
 
     The <identifier> is a fully-qualified Kerberos principal.  Access is
     granted if the principal of the client matches <identifier>.
 
+  ldap-attr
+
+    <identifier> is an an attribute followed by an equal sign and a value.
+    If the LDAP entry corresponding to the given principal contains the
+    attribute and value specified by <identifier>, access is granted.
+
+  ldap-attr-root
+
+    This is almost identical to netdb except that the user must be in the
+    form of a root instance (<user>/root) and the "/root" portion is
+    stripped before checking the NetDB roles.
+
+  nested
+
+    <identifier> is the name of another ACL, and access is granted if it
+    is granted by that ACL.  This can be used to organize multiple ACLs
+    into a group and apply their union to an object.
+
   netdb
 
     <identifier> is the name of a system.  Access is granted if the user
@@ -67,13 +92,6 @@ ACL Schemes
     form of a root instance (<user>/root) and the "/root" portion is
     stripped before checking the NetDB roles.
 
-  ldap-entitlement
-
-    (Not yet implemented.)  <identifier> is an entitlement.  If the
-    entitlement attribute of the LDAP entry corresponding to the given
-    principal contains the entitlement specified in <identifier>, access
-    is granted.
-
   pts
 
     (Not yet implemented.)  <identifier> is the name of an AFS PTS group.
@@ -82,6 +100,7 @@ ACL Schemes
 
 License
 
+    Copyright 2016 Russ Allbery <eagle@eyrie.org>
     Copyright 2006, 2007, 2008, 2013
         The Board of Trustees of the Leland Stanford Junior University
 
diff --git a/docs/objects-and-schemes b/docs/objects-and-schemes
index 97e6289..763a24b 100644
--- a/docs/objects-and-schemes
+++ b/docs/objects-and-schemes
@@ -10,17 +10,21 @@ Introduction
 
 Object Types
 
-  duo
+  duo-ldap
+  duo-pam
+  duo-radius
+  duo-rdp
 
     Stores the configuration for a Duo Security integration.  Duo is a
     cloud provider of multifactor authentication services.  A Duo
     integration consists of some local configuration and a secret key that
     permits verification of a second factor using the Duo cloud service.
-    Currently, only UNIX integrations are supported.  In the future, this
-    object type will likely be split into several object types
-    corresponding to the supported types of Duo integrations.
+    Each of these types is the same except for the output, which is
+    specialized towards giving information in the format suited for a
+    specific application.
 
-    Implemented via Wallet::Object::Duo.
+    Implemented via Wallet::Object::Duo::PAM, Wallet::Object::Duo::RDP,
+    Wallet::Object::Duo::LDAPProxy, Wallet::Object::Duo::RadiusProxy.
 
   file
 
@@ -33,6 +37,16 @@ Object Types
 
     Implemented via Wallet::Object::File.
 
+  password
+
+    Stores a file with single password in it and allows retrieval of that
+    file.  This is built on the file object and is almost entirely
+    identical in function.  It adds the ability to automatically generate
+    randomized content if you get the object before it's been stored,
+    letting you get autogenerated passwords.
+
+    Implemented via Wallet::Object::Password.
+
   keytab
 
     Stores a keytab representing private keys for a given Kerberos
diff --git a/docs/stanford-naming b/docs/stanford-naming
index c86c820..cb05a23 100644
--- a/docs/stanford-naming
+++ b/docs/stanford-naming
@@ -90,27 +90,6 @@ Object Naming
 
         (OLD: <group>-<server>-htpasswd-<app>)
 
-    password-ipmi/<server>
-
-        Stores the password for remote IPMI/iLO/ILOM access to the
-        system.
-
-        (OLD: <group>-<server>-password-ipmi)
-
-    password-root/<server>
-
-        Stores the root password for a given server.
-
-        (OLD: <group>-<server>-password-root)
-
-    password-tivoli/<server>
-
-        Stores the Tivoli TSM backup password for a given server.  See
-        also tivoli-key/<server>, but depending on what one wants to do
-        with the password, this may be a better representation.
-
-        (OLD: <group>-<server>-password-tivoli)
-
     ssh-<type>/<server>
 
         Stores the SSH private key for <server>.  For shared private keys
@@ -197,20 +176,6 @@ Object Naming
 
         (OLD: <group>-<service>-gpg-key)
 
-    password/<group>/<service>/<name>
-
-        A password for some account, service, keystore, or something
-        similar that is not covered by one of the more specific naming
-        conventions, such as a password used to connect to a remote ssh
-        service.  <service> is the service that uses this password and
-        <name> is the thing the password is used for (such as the remote
-        account name).  This may be a file containing only the password,
-        or a configuration file of some type that includes a field name
-        and the password.  (However, use the db type described above for
-        database passwords.)
-
-        (OLD: <group>-<server>-password-<account>)
-
     properties/<group>/<service>[/<name>]
 
         The properties file for a Java application that contains some
@@ -262,6 +227,68 @@ Object Naming
     <group>-<server>-pam-<app>
     <group>-<service>-puppetconf
     <group>-<service>-shibboleth
+    <group>-<server>-password-ipmi
+    <group>-<server>-password-root
+    <group>-<server>-password-tivoli
+    <group>-<server>-password-<account>
+
+    Replaced by password objects:
+
+    password-ipmi/<server>
+    password-root/<server>
+    password-tivoli/<server>
+
+    password/<group>/<service>/<name> should be replaced by the password
+    service/<group>/<service>/<name> object if a single password, or by
+    the file object db/* or config/* format if the object contains more
+    than just the bare password.
+
+  Password
+
+    Passwords are a recent type and so most password data is actually
+    in file objects.  However, we'd like to move things there both for
+    the added features of password objects to self-set, and because it
+    helps clean up the file namespace a little more.
+
+    Host-based:
+
+    ipmi/<server>
+
+        Stores the password for remote IPMI/iLO/ILOM access to the
+        system.
+
+    tivoli/<server>
+
+        Stores the Tivoli TSM backup password for a given server.  See
+        also tivoli-key/<server> in the file section, but depending on
+        what one wants to do with the password, this may be a better
+        representation.
+
+    root/<server>
+
+        Stores the root password for a given server.
+
+    system/<server>/<account>
+
+        Stores the password for a non-root system account, such as a user
+        required for file uploads.
+
+    app/<server>/<application>
+
+        Stores an application password bound to a certain server.
+
+    Service-based:
+
+    service/<group>/<service>/<name>
+
+        A password for some account, service, keystore, or something
+        similar that is not covered by one of the more specific naming
+        conventions, such as a password used to connect to a remote ssh
+        service.  <service> is the service that uses this password and
+        <name> is the thing the password is used for (such as the remote
+        account name).  This should only be for something including the
+        password and nothing else.  See the file password/ object name
+        for something that includes more data.
 
 ACL Naming