From ac639ee085c464a0098bd85b9cba9ab7155f27c7 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Fri, 7 Aug 2009 14:21:52 -0700 Subject: Update Stanford naming documentation for puppet.conf Add a naming convention for puppet.conf files containing secure data and reorganize the naming convention documentation to group all service objects together. --- docs/stanford-naming | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) (limited to 'docs') diff --git a/docs/stanford-naming b/docs/stanford-naming index f887a69..3c6330b 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -70,13 +70,6 @@ Object Naming Then, we use the following naming conventions for different types of objects: - --db- - - Stores the database password for the database named . This - may be a file containing only the database password or a Perl - AppConfig configuration file with the database connection - information including the password. - --htpasswd- An .htpasswd file for HTTP Basic Authentication for special-case @@ -109,6 +102,13 @@ Object Naming The public certificate we manage external to wallet since it doesn't need to be protected or encrypted. + --db- + + Stores the database password for the database named . This + may be a file containing only the database password or a Perl + AppConfig configuration file with the database connection + information including the password. + --gpg-key Stores the GnuPG private key for a service that needs to do GnuPG @@ -122,6 +122,13 @@ Object Naming sometimes it's too hard to separate out chunks of a properties file. + --puppetconf + + A puppet.conf configuration file for Puppet that contains some + secure data (such as SSL key passwords or database passwords). + Ideally the secure data should be stored in separate files, but + Puppet likes to use a single configuration file. + --shibboleth The shibboleth.xml configuration file for a service, when it -- cgit v1.2.3 From b87c38cb69f9b43894c377cd9370ec3e8c42d4cc Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Sat, 15 Aug 2009 15:42:26 -0700 Subject: Add a naming convention for general config files We have some general configuration files that contain database passwords. Add a general naming convention to avoid creating new ones with each new type of config file. --- docs/stanford-naming | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'docs') diff --git a/docs/stanford-naming b/docs/stanford-naming index 3c6330b..94537bb 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -102,6 +102,15 @@ Object Naming The public certificate we manage external to wallet since it doesn't need to be protected or encrypted. + --config- + + A configuration file named that contains some secure + information, such as a database password. Ideally, the secure + data should be stored in a separate file and assembled into the + configuration file, but that isn't always the path of least + resistance. Only use this naming convention if there is not a + more specific one below. + --db- Stores the database password for the database named . This -- cgit v1.2.3 From 56b95aca27c49538a3c306ac0fe5cf537c3441f0 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Tue, 15 Sep 2009 17:44:58 -0700 Subject: Add Tivoli encryption keys to the Stanford naming guide --- docs/stanford-naming | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'docs') diff --git a/docs/stanford-naming b/docs/stanford-naming index 94537bb..f2a45a7 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -102,6 +102,14 @@ Object Naming The public certificate we manage external to wallet since it doesn't need to be protected or encrypted. + --tivoli-key + + The Tivoli backup encryption key for this server. This is stored + in the same file as the password used to connect to the Tivoli + server, so both are stored together. This file is found at + /etc/adsm/TSM.PWD. It must be base64-encoded before being stored + in the wallet. + --config- A configuration file named that contains some secure -- cgit v1.2.3 From 4f863ccc9531130be3f4aecea341a0e8a66c6f8c Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Sat, 20 Feb 2010 20:30:37 -0800 Subject: wallet-backend gets the third store argument from stdin if missing If there is no third argument to store, read it from standard input instead. This is the preferred way of running wallet-backend, using stdin=last support from remctl 2.14 and later. Receiving the third argument as a regular argument continues to be supported for backward compatibility. --- config/wallet | 2 +- docs/setup | 8 ++++---- server/wallet-backend | 11 ++++++++--- tests/server/backend-t | 26 +++++++++++++++++++++++--- 4 files changed, 36 insertions(+), 11 deletions(-) (limited to 'docs') diff --git a/config/wallet b/config/wallet index 2e0b142..06dc39d 100644 --- a/config/wallet +++ b/config/wallet @@ -3,5 +3,5 @@ # This is a remctld configuration fragment to run wallet-backend, which # implements the server side of the wallet system. -wallet store /usr/sbin/wallet-backend logmask=4 ANYUSER +wallet store /usr/sbin/wallet-backend stdin=4 ANYUSER wallet ALL /usr/sbin/wallet-backend ANYUSER diff --git a/docs/setup b/docs/setup index ac83949..5a0036f 100644 --- a/docs/setup +++ b/docs/setup @@ -64,10 +64,10 @@ Wallet Configuration On the wallet server, install remctld. Then, install the configuration fragment in config/wallet in the remctld configuration. - You can do this either by adding the one non-comment line of that file - to your remctl.conf or, if your remctl.conf includes a directory of - configuration fragments, drop config/wallet into that directory. You - may need to change the path to wallet-backend. + You can do this either by adding the two non-comment lines of that + file to your remctl.conf or, if your remctl.conf includes a directory + of configuration fragments, drop config/wallet into that directory. + You may need to change the path to wallet-backend. Note that the default wallet configuration allows any authenticated user to run the wallet backend and relies on the wallet's ACLs for all diff --git a/server/wallet-backend b/server/wallet-backend index 7780758..453aa79 100755 --- a/server/wallet-backend +++ b/server/wallet-backend @@ -284,7 +284,11 @@ sub command { failure ($server->error, @_); } } elsif ($command eq 'store') { - check_args (3, 3, [3], @args); + check_args (2, 3, [3], @args); + if (@args == 2) { + local $/; + $args[2] = ; + } splice (@_, 3); $server->store (@args) or failure ($server->error, @_); } else { @@ -536,10 +540,11 @@ name, the owner, any specific ACLs set on the object, the expiration if any, and the user, remote host, and time when the object was created, last stored, and last downloaded. -=item store +=item store [] Stores for the object identified by and for later -retrieval with C. Not all object types support this. +retrieval with C. Not all object types support this. If is +not given as an argument, it will be read from standard input. Currently, is limited to not containing nul characters and may therefore not be binary data, and is limited by the maximum command line diff --git a/tests/server/backend-t b/tests/server/backend-t index 2fc6a53..b58d02c 100755 --- a/tests/server/backend-t +++ b/tests/server/backend-t @@ -9,7 +9,7 @@ # See LICENSE for licensing terms. use strict; -use Test::More tests => 1263; +use Test::More tests => 1269; # Create a dummy class for Wallet::Server that prints what method was called # with its arguments and returns data for testing. @@ -163,6 +163,7 @@ package main; $INC{'Wallet/Server.pm'} = 'FAKE'; my $OUTPUT; our $SYSLOG = \$OUTPUT; +my $INPUT = ''; eval { do "$ENV{SOURCE}/../server/wallet-backend" }; # Run the wallet backend. This fun hack takes advantage of the fact that the @@ -173,6 +174,8 @@ sub run_backend { my $result = ''; open (OUTPUT, '>', \$result) or die "cannot create output string: $!\n"; select OUTPUT; + close STDIN; + open (STDIN, '<', \$INPUT) or die "cannot change stdin: $!\n"; local $| = 1; eval { command (@args) }; my $error = $@; @@ -224,7 +227,7 @@ my %commands = (autocreate => [2, 2], setacl => [4, 4], setattr => [4, 9], show => [2, 2], - store => [3, 3]); + store => [2, 3]); my %acl_commands = (add => [3, 3], create => [1, 1], destroy => [1, 1], @@ -326,6 +329,7 @@ for my $command (qw/autocreate create destroy setacl setattr store/) { $method ||= $command; my @extra = ('foo') x ($commands{$command}[0] - 2); my $extra = @extra ? join (' ', '', @extra) : ''; + $extra = ' ' if $command eq 'store'; ($out, $err) = run_backend ($command, 'type', 'name', @extra); my $ran; if ($command eq 'store') { @@ -413,7 +417,7 @@ for my $command (qw/check expires get getacl getattr history owner show/) { ' and ran the right method with output'); } ($out, $err) = run_backend ($command, 'error', 'name', @extra); - my $ran = "$command error name" . (@extra ? " @extra" : ''); + $ran = "$command error name" . (@extra ? " @extra" : ''); is ($err, "error count $error\n", "Command $command ran with errors"); is ($OUTPUT, "command $ran from admin (1.2.3.4) failed: error count" . " $error\n", ' and syslog correct'); @@ -468,6 +472,22 @@ for my $command (sort keys %flag_commands) { $error++; } +# Special check for store allowing nul characters on standard input. +$INPUT = "Some data\000with a nul character"; +($out, $err) = run_backend ('store', 'type', 'name'); +is ($err, '', 'store with nul data ran with no errors'); +is ($OUTPUT, "command store type name from admin (1.2.3.4) succeeded\n", + ' and success logged'); +is ($out, "$new\nstore type name $INPUT\n", + ' and ran the right method'); +$INPUT = ''; +($out, $err) = run_backend ('store', 'type', 'name'); +is ($err, '', 'store with empty stdin data ran with no errors'); +is ($OUTPUT, "command store type name from admin (1.2.3.4) succeeded\n", + ' and success logged'); +is ($out, "$new\nstore type name \n", + ' and ran the right method'); + # Almost done. All that remains is to test the robustness of the bad # character checks against every possible character and test permitting the # empty argument. -- cgit v1.2.3 From ec85907906ede72ffd95164de2726abfc076b719 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Wed, 14 Apr 2010 18:04:52 -0700 Subject: Update Stanford naming for Tivoli keys The previous wording implied that --tivoli-key was only used for encryption keys. Allow for either passwords or encryption keys, and remove the note that it should be base64-encoded since wallet now supports binary files. --- docs/stanford-naming | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) (limited to 'docs') diff --git a/docs/stanford-naming b/docs/stanford-naming index f2a45a7..7315c1e 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -104,11 +104,10 @@ Object Naming --tivoli-key - The Tivoli backup encryption key for this server. This is stored - in the same file as the password used to connect to the Tivoli - server, so both are stored together. This file is found at - /etc/adsm/TSM.PWD. It must be base64-encoded before being stored - in the wallet. + The Tivoli password or backup encryption key for this server. + Both the password and the encryption key, if used, are stored in + the same file, so both are stored together. This file is found at + /etc/adsm/TSM.PWD. --config- -- cgit v1.2.3 From e29ae427336d50d6109729718f603a8c0ec38095 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Wed, 23 Mar 2011 13:25:36 -0700 Subject: Add -ssl-keystore to the Stanford naming conventions --- docs/stanford-naming | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'docs') diff --git a/docs/stanford-naming b/docs/stanford-naming index 7315c1e..a1855f8 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -153,6 +153,13 @@ Object Naming files and assembled into a shibboleth.xml file, but that isn't always the path of least resistance. + --ssl-keystore + + The Java keystore file (containing both public and private key) + used by a service for authentication to other services. If a + given service uses more than one, include the purpose in the + part of the name. + --ssl-pkcs12 The PKCS#12 file (containing both public and private key) used by -- cgit v1.2.3 From 7b9d4ca1375949349c9be4456a8963c7e85baa9b Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Thu, 29 Mar 2012 13:53:42 -0700 Subject: Fix incorrect wallet.conf path in the setup documentation --- docs/setup | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/setup b/docs/setup index 5a0036f..b8854fc 100644 --- a/docs/setup +++ b/docs/setup @@ -34,7 +34,7 @@ SQLite Database Setup SQLite is very nice in that you don't have to create the database first. You don't even have to create the file. Just create - /etc/wallet.conf with something like: + /etc/wallet/wallet.conf with something like: $DB_DRIVER = 'SQLite'; $DB_INFO = '/path/to/database'; -- cgit v1.2.3 From f7df31d3cf7580e8cccdea0110f35202b42b87d1 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Mon, 16 Jul 2012 16:51:14 -0700 Subject: Add documentation of existing wallet objects and ACL schemes --- docs/objects-and-types | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 docs/objects-and-types (limited to 'docs') diff --git a/docs/objects-and-types b/docs/objects-and-types new file mode 100644 index 0000000..9d92c7b --- /dev/null +++ b/docs/objects-and-types @@ -0,0 +1,90 @@ + Supported Object Types and ACL Schemes + +Introduction + + This is a list of all supported wallet object types and ACL schemes in + the current version of wallet, with some brief information about the + properties of each one. For more detailed documentation, see the + documentation of the underlying Wallet::Object::* class or + Wallet::ACL::* class referenced here. + +Object Types + + file + + Stores an arbitrary file and allows retrieval of that file. The file + must be stored before it can be retrieved. All files are stored on + the local file system of the wallet server in a directory organized by + a hash of the name of the file object. The size of file objects is + limited by wallet server configuration. File contents may include nul + characters. + + Implemented via Wallet::Object::File. + + keytab + + Stores a keytab representing private keys for a given Kerberos + principal. The object name is the Kerberos principal (without the + realm). On object creation, the Kerberos principal is created in the + underlying KDC; on object destruction, the Kerberos principal is also + deleted. Normally, any retrieval of the object creates new random + keys for all supported enctypes and then returns a new keytab + containing those keys. Store is not supported. + + Keytab objects with the unchanging flag set will retrieve the existing + keys from the Kerberos KDC instead of randomizing the keys. For MIT + Kerberos, this requires a custom backend be installed on the KDC. + + The enctypes of the returned keys can be restricted by setting the + enctypes attribute on the wallet object. + + Implemented via Wallet::Object::Keytab. + +ACL Schemes + + krb5 + + The value is a string representation of a Kerberos principal name. + This ACL grants access if the authenticated wallet client user (as + determined by remctl or whatever other protocol is used for the wallet + transport) equals the ACL value. + + Implemented via Wallet::ACL::Krb5. + + krb5-regex + + Like krb5, but instead of taking the principal string, takes a regular + expression that is matched against the principal string. Grants + access if the regular expression matches the user identity. + + Implemented via Wallet::ACL::Krb5::Regex. + + ldap-attr + + The value is an LDAP attribute, an equal sign, and the value that + attribute must have. The LDAP entry for the user (determined via + site-local customization in the wallet configuration file) is + retrieved, and the wallet server checks that the user's LDAP entry + contains that attribute with that value. If so, access is granted. + This effectively implements an entitlement check. + + Implemented via Wallet::ACL::LDAP::Attribute. + + netdb + + The value is a hostname. NetDB (a system for managing DNS, DHCP, and + related machine information) is queried to see what roles the client + user has for that hostname. If the user has a role of user, admin, or + team, the ACL grants access. + + Implemented via Wallet::ACL::NetDB. + + netdb-root + + Identical to netdb, except that the user identity is taken as a + Kerberos principal and must be in the form of /root@. + The /root part is stripped before checking NetDB for roles. This + forces users to use /root instances for wallet operations instead of + their normal principals. + + Implemented via Wallet::ACL::NetDB::Root. -- cgit v1.2.3 From 6ab69d850ec27889ebc21da0bacc4aa5adf7ce97 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Mon, 16 Jul 2012 16:54:47 -0700 Subject: Add objects-and-schemes to EXTRA_DIST, rename --- Makefile.am | 40 +++++++++++---------- docs/objects-and-schemes | 90 ++++++++++++++++++++++++++++++++++++++++++++++++ docs/objects-and-types | 90 ------------------------------------------------ 3 files changed, 111 insertions(+), 109 deletions(-) create mode 100644 docs/objects-and-schemes delete mode 100644 docs/objects-and-types (limited to 'docs') diff --git a/Makefile.am b/Makefile.am index 444df0b..1c42b2d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -28,25 +28,27 @@ PERL_FILES = perl/Wallet/ACL.pm perl/Wallet/ACL/Base.pm \ AUTOMAKE_OPTIONS = foreign subdir-objects ACLOCAL_AMFLAGS = -I m4 -EXTRA_DIST = .gitignore LICENSE autogen client/wallet.pod \ - client/wallet-rekey.pod config/allow-extract config/keytab \ - config/keytab.acl config/wallet config/wallet-report.acl docs/design \ - contrib/README contrib/convert-srvtab-db contrib/used-principals \ - contrib/wallet-contacts contrib/wallet-summary \ - contrib/wallet-summary.8 contrib/wallet-unknown-hosts \ - docs/design-acl docs/design-api docs/netdb-role-api docs/notes \ - docs/setup docs/stanford-naming examples/stanford.conf tests/TESTS \ - tests/data/README tests/data/allow-extract tests/data/basic.conf \ - tests/data/cmd-fake tests/data/cmd-wrapper tests/data/fake-data \ - tests/data/fake-kadmin tests/data/fake-keytab \ - tests/data/fake-keytab-2 tests/data/fake-keytab-foreign \ - tests/data/fake-keytab-merge tests/data/fake-keytab-old \ - tests/data/fake-keytab-partial tests/data/fake-keytab-partial-result \ - tests/data/fake-keytab-rekey tests/data/fake-keytab-unknown \ - tests/data/fake-srvtab tests/data/full.conf tests/data/wallet.conf \ - tests/docs/pod-spelling-t tests/docs/pod-t tests/server/admin-t \ - tests/server/backend-t tests/server/keytab-t tests/server/report-t \ - tests/tap/kerberos.sh tests/tap/libtap.sh tests/tap/remctl.sh \ +EXTRA_DIST = .gitignore LICENSE autogen client/wallet.pod \ + client/wallet-rekey.pod config/allow-extract config/keytab \ + config/keytab.acl config/wallet config/wallet-report.acl \ + docs/design contrib/README contrib/convert-srvtab-db \ + contrib/used-principals contrib/wallet-contacts \ + contrib/wallet-summary contrib/wallet-summary.8 \ + contrib/wallet-unknown-hosts docs/design-acl docs/design-api \ + docs/netdb-role-api docs/notes docs/objects-and-schemes docs/setup \ + docs/stanford-naming examples/stanford.conf tests/TESTS \ + tests/data/README tests/data/allow-extract tests/data/basic.conf \ + tests/data/cmd-fake tests/data/cmd-wrapper tests/data/fake-data \ + tests/data/fake-kadmin tests/data/fake-keytab \ + tests/data/fake-keytab-2 tests/data/fake-keytab-foreign \ + tests/data/fake-keytab-merge tests/data/fake-keytab-old \ + tests/data/fake-keytab-partial \ + tests/data/fake-keytab-partial-result tests/data/fake-keytab-rekey \ + tests/data/fake-keytab-unknown tests/data/fake-srvtab \ + tests/data/full.conf tests/data/wallet.conf \ + tests/docs/pod-spelling-t tests/docs/pod-t tests/server/admin-t \ + tests/server/backend-t tests/server/keytab-t tests/server/report-t \ + tests/tap/kerberos.sh tests/tap/libtap.sh tests/tap/remctl.sh \ tests/util/xmalloc-t $(PERL_FILES) noinst_LIBRARIES = portable/libportable.a util/libutil.a diff --git a/docs/objects-and-schemes b/docs/objects-and-schemes new file mode 100644 index 0000000..9d92c7b --- /dev/null +++ b/docs/objects-and-schemes @@ -0,0 +1,90 @@ + Supported Object Types and ACL Schemes + +Introduction + + This is a list of all supported wallet object types and ACL schemes in + the current version of wallet, with some brief information about the + properties of each one. For more detailed documentation, see the + documentation of the underlying Wallet::Object::* class or + Wallet::ACL::* class referenced here. + +Object Types + + file + + Stores an arbitrary file and allows retrieval of that file. The file + must be stored before it can be retrieved. All files are stored on + the local file system of the wallet server in a directory organized by + a hash of the name of the file object. The size of file objects is + limited by wallet server configuration. File contents may include nul + characters. + + Implemented via Wallet::Object::File. + + keytab + + Stores a keytab representing private keys for a given Kerberos + principal. The object name is the Kerberos principal (without the + realm). On object creation, the Kerberos principal is created in the + underlying KDC; on object destruction, the Kerberos principal is also + deleted. Normally, any retrieval of the object creates new random + keys for all supported enctypes and then returns a new keytab + containing those keys. Store is not supported. + + Keytab objects with the unchanging flag set will retrieve the existing + keys from the Kerberos KDC instead of randomizing the keys. For MIT + Kerberos, this requires a custom backend be installed on the KDC. + + The enctypes of the returned keys can be restricted by setting the + enctypes attribute on the wallet object. + + Implemented via Wallet::Object::Keytab. + +ACL Schemes + + krb5 + + The value is a string representation of a Kerberos principal name. + This ACL grants access if the authenticated wallet client user (as + determined by remctl or whatever other protocol is used for the wallet + transport) equals the ACL value. + + Implemented via Wallet::ACL::Krb5. + + krb5-regex + + Like krb5, but instead of taking the principal string, takes a regular + expression that is matched against the principal string. Grants + access if the regular expression matches the user identity. + + Implemented via Wallet::ACL::Krb5::Regex. + + ldap-attr + + The value is an LDAP attribute, an equal sign, and the value that + attribute must have. The LDAP entry for the user (determined via + site-local customization in the wallet configuration file) is + retrieved, and the wallet server checks that the user's LDAP entry + contains that attribute with that value. If so, access is granted. + This effectively implements an entitlement check. + + Implemented via Wallet::ACL::LDAP::Attribute. + + netdb + + The value is a hostname. NetDB (a system for managing DNS, DHCP, and + related machine information) is queried to see what roles the client + user has for that hostname. If the user has a role of user, admin, or + team, the ACL grants access. + + Implemented via Wallet::ACL::NetDB. + + netdb-root + + Identical to netdb, except that the user identity is taken as a + Kerberos principal and must be in the form of /root@. + The /root part is stripped before checking NetDB for roles. This + forces users to use /root instances for wallet operations instead of + their normal principals. + + Implemented via Wallet::ACL::NetDB::Root. diff --git a/docs/objects-and-types b/docs/objects-and-types deleted file mode 100644 index 9d92c7b..0000000 --- a/docs/objects-and-types +++ /dev/null @@ -1,90 +0,0 @@ - Supported Object Types and ACL Schemes - -Introduction - - This is a list of all supported wallet object types and ACL schemes in - the current version of wallet, with some brief information about the - properties of each one. For more detailed documentation, see the - documentation of the underlying Wallet::Object::* class or - Wallet::ACL::* class referenced here. - -Object Types - - file - - Stores an arbitrary file and allows retrieval of that file. The file - must be stored before it can be retrieved. All files are stored on - the local file system of the wallet server in a directory organized by - a hash of the name of the file object. The size of file objects is - limited by wallet server configuration. File contents may include nul - characters. - - Implemented via Wallet::Object::File. - - keytab - - Stores a keytab representing private keys for a given Kerberos - principal. The object name is the Kerberos principal (without the - realm). On object creation, the Kerberos principal is created in the - underlying KDC; on object destruction, the Kerberos principal is also - deleted. Normally, any retrieval of the object creates new random - keys for all supported enctypes and then returns a new keytab - containing those keys. Store is not supported. - - Keytab objects with the unchanging flag set will retrieve the existing - keys from the Kerberos KDC instead of randomizing the keys. For MIT - Kerberos, this requires a custom backend be installed on the KDC. - - The enctypes of the returned keys can be restricted by setting the - enctypes attribute on the wallet object. - - Implemented via Wallet::Object::Keytab. - -ACL Schemes - - krb5 - - The value is a string representation of a Kerberos principal name. - This ACL grants access if the authenticated wallet client user (as - determined by remctl or whatever other protocol is used for the wallet - transport) equals the ACL value. - - Implemented via Wallet::ACL::Krb5. - - krb5-regex - - Like krb5, but instead of taking the principal string, takes a regular - expression that is matched against the principal string. Grants - access if the regular expression matches the user identity. - - Implemented via Wallet::ACL::Krb5::Regex. - - ldap-attr - - The value is an LDAP attribute, an equal sign, and the value that - attribute must have. The LDAP entry for the user (determined via - site-local customization in the wallet configuration file) is - retrieved, and the wallet server checks that the user's LDAP entry - contains that attribute with that value. If so, access is granted. - This effectively implements an entitlement check. - - Implemented via Wallet::ACL::LDAP::Attribute. - - netdb - - The value is a hostname. NetDB (a system for managing DNS, DHCP, and - related machine information) is queried to see what roles the client - user has for that hostname. If the user has a role of user, admin, or - team, the ACL grants access. - - Implemented via Wallet::ACL::NetDB. - - netdb-root - - Identical to netdb, except that the user identity is taken as a - Kerberos principal and must be in the form of /root@. - The /root part is stripped before checking NetDB for roles. This - forces users to use /root instances for wallet operations instead of - their normal principals. - - Implemented via Wallet::ACL::NetDB::Root. -- cgit v1.2.3 From b67dd35066a85df0f4c04e9cbde33a20b0492c24 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Thu, 17 Jan 2013 15:50:30 -0800 Subject: Significant revision of the Stanford naming scheme Recommend slash-separated names by default. Remove some obsolete bits and update a lot of the recommendations and wording. Change-Id: I44cbf8116e7529b00a61261248ff9daecacdb910 Reviewed-on: https://gerrit.stanford.edu/723 Reviewed-by: Russ Allbery Tested-by: Russ Allbery --- docs/stanford-naming | 145 ++++++++++++++++++++++++++++++++------------------- 1 file changed, 90 insertions(+), 55 deletions(-) (limited to 'docs') diff --git a/docs/stanford-naming b/docs/stanford-naming index a1855f8..b6e9f63 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -63,113 +63,148 @@ Object Naming convention for that type of thing. All file object names start with a short indicator of the responsible - group, a dash, and then either the short, unqualified hostname (if + group, a slash, the type of object, a slash, and then the hostname (if they're only used on a single host) or the service name for which that - object is used. + object is used. The hostname is normally presented without the domain + if it's a normal .stanford.edu host. + + We previously instead used --, but that caused + various problems in parsing because groups, servers, and types all + also contained dashes. Slashes are much less ambiguous. This + document shows both the new and the old form. Then, we use the following naming conventions for different types of - objects: + objects. + + Host-based: - --htpasswd- + /htpasswd// An .htpasswd file for HTTP Basic Authentication for special-case web configurations that require such a thing. - --pam- - - A PAM configuration for that requires secure information, - such as a password for pam_msyql. may be either a - specific server name or a general class of servers (production and - test) that uses that PAM configuration. - - --password- + (OLD: --htpasswd-) - A password for some account that isn't covered by one of the more - specific naming conventions, such as a password used to connect to - a remote ssh service. - - --ssh- + /ssh-/ Stores the SSH private key for . For shared private keys across a pool, should be the name of the pool, or possibly some unambiguous name for the set of systems. is the type of SSH key (RSA or DSA). - --ssl-key + (OLD: --ssh-) + + /ssl-key/ + + Stores the SSL X.509 certificate private key for . Used + for Apache, Postfix, LDAP, and similar cases where the certificate + should match the host name. The public certificate we manage + external to wallet since it doesn't need to be protected or + encrypted. + + Use idg/ssl-key/starYYYY for the key for the *.stanford.edu + certificate, where YYYY is the expiration year. - Stores the SSL X.509 certificate private key for . Use - unix-star-ssl-key for the key for the *.stanford.edu certificate. - The public certificate we manage external to wallet since it - doesn't need to be protected or encrypted. + (OLD: --ssl-key) - --tivoli-key + /tivoli-key/ The Tivoli password or backup encryption key for this server. Both the password and the encryption key, if used, are stored in the same file, so both are stored together. This file is found at /etc/adsm/TSM.PWD. - --config- + (OLD: --tivoli-key) + + In all cases, is the server (or group of servers) on which + the file will be stored, not the server expecting that key material + for authentication. + + Service-based: + + /config/- A configuration file named that contains some secure information, such as a database password. Ideally, the secure data should be stored in a separate file and assembled into the - configuration file, but that isn't always the path of least - resistance. Only use this naming convention if there is not a - more specific one below. + configuration file. This is reserved for configuration files that + hold nothing but authentication information. Only use this naming + convention if there is not a more specific one below. + + (OLD: --config-) - --db- + /db// - Stores the database password for the database named . This - may be a file containing only the database password or a Perl - AppConfig configuration file with the database connection - information including the password. + Stores the database password for access to the database + named . This may be a file containing only the database + password or a Perl AppConfig configuration file with the database + connection information including the password. - --gpg-key + (OLD: --db-) + + /gpg-key/ Stores the GnuPG private key for a service that needs to do GnuPG signing or encryption. - --properties + (OLD: --gpg-key) - The properties file for a Java application that contains some - secure data (such as SSL key passwords or database passwords). - Ideally the secure data should be stored in separate files, but - sometimes it's too hard to separate out chunks of a properties - file. + /password/- - --puppetconf + A password for some account, service, keystore, or something + similar that covered by one of the more specific naming + conventions, such as a password used to connect to a remote ssh + service. is the service that uses this password and + 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.) - A puppet.conf configuration file for Puppet that contains some - secure data (such as SSL key passwords or database passwords). - Ideally the secure data should be stored in separate files, but - Puppet likes to use a single configuration file. + (OLD: --password-) - --shibboleth + /properties/ - The shibboleth.xml configuration file for a service, when it - contains some secure data (such as database passwords for shared - sessions). Ideally, the secure data should be stored in separate - files and assembled into a shibboleth.xml file, but that isn't - always the path of least resistance. + The properties file for a Java application that contains some + secure data (such as SSL key passwords or database passwords). + This should only be used for a properties file that contains only + the password and closely-related information, such as database + connection information. For anything else, switch to storing the + password separately using the password type above and building the + properties file dynamically from the password and a template. + + (OLD: --properties) - --ssl-keystore + /ssl-keystore/ The Java keystore file (containing both public and private key) used by a service for authentication to other services. If a given service uses more than one, include the purpose in the part of the name. - --ssl-pkcs12 + (OLD: --ssl-keystore) + + /ssl-pkcs12/ The PKCS#12 file (containing both public and private key) used by a service for authentication to other services. If a given service uses more than one, include the purpose in the part of the name. - In all cases, is the server (or group of servers) on which - the file will be stored, not the server expecting that key material - for authentication. + (OLD: --ssl-pkcs12) + + We previously stored a wider variety of configuration files before + developing a way to dynamically substitute the password into a larger + configuration file during deployment. The following file types are + obsolete and should no longer be used; instead, the configuration file + should be constructed by substituting a password (usually stored as a + password or db type) into the configuration file. + + Obsolete: + + --pam- + --puppetconf + --shibboleth ACL Naming -- cgit v1.2.3 From 6530fb472f1c64d3e80c723d3073ca3d256a58ce Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Fri, 18 Jan 2013 11:48:45 -0800 Subject: Further Stanford naming convention changes Remove the group for host-based file object names. Move the group to the second component for non-host-based names so that the first component is always the object type. Add some additional object types and clarify wording based on feedback from Adam. Change-Id: I5db7b23d2b004c69afb869df5624d455b751c0d5 Reviewed-on: https://gerrit.stanford.edu/724 Reviewed-by: Russ Allbery Tested-by: Russ Allbery --- docs/stanford-naming | 103 ++++++++++++++++++++++++++++++++++----------------- 1 file changed, 70 insertions(+), 33 deletions(-) (limited to 'docs') diff --git a/docs/stanford-naming b/docs/stanford-naming index b6e9f63..f88d148 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -62,52 +62,80 @@ Object Naming it should get its own object type first and to agree on a naming convention for that type of thing. - All file object names start with a short indicator of the responsible - group, a slash, the type of object, a slash, and then the hostname (if - they're only used on a single host) or the service name for which that - object is used. The hostname is normally presented without the domain - if it's a normal .stanford.edu host. + There are two basic types of file objects: ones that are tied to a + particular system, and ones that are not. For the ones that are tied + to a particular system, we use a naming convention very similar to + host-based Kerberos principals so that we can set up default ACLs + based on the host. For ones that are not, we require an indication of + the repsonsible group in each file object, since the rest of the name + can often be ambiguous. + + File objects are named with two or more slash-separated components + (again, similar to Kerberos principals). The first is the type of + file being stored. The rest vary based on the file type. We previously instead used --, but that caused various problems in parsing because groups, servers, and types all also contained dashes. Slashes are much less ambiguous. This document shows both the new and the old form. - Then, we use the following naming conventions for different types of - objects. - Host-based: - /htpasswd// + htpasswd// An .htpasswd file for HTTP Basic Authentication for special-case - web configurations that require such a thing. + web configurations that require such a thing. is the + server (or group of servers) on which the file will be stored (OLD: --htpasswd-) - /ssh-/ + password-ipmi/ + + Stores the password for remote IPMI/iLO/ILOM access to the + system. + + (OLD: --password-ipmi) + + password-root/ + + Stores the root password for a given server. + + (OLD: --password-root) + + password-tivoli/ + + Stores the Tivoli TSM backup password for a given server. See + also tivoli-key/, but depending on what one wants to do + with the password, this may be a better representation. + + (OLD: --password-tivoli) + + ssh-/ Stores the SSH private key for . For shared private keys across a pool, should be the name of the pool, or possibly some unambiguous name for the set of systems. is - the type of SSH key (RSA or DSA). + the type of SSH key (rsa or dsa, in lowercase). (OLD: --ssh-) - /ssl-key/ + ssl-key/ Stores the SSL X.509 certificate private key for . Used for Apache, Postfix, LDAP, and similar cases where the certificate should match the host name. The public certificate we manage external to wallet since it doesn't need to be protected or - encrypted. + encrypted. here should be the CN of the certificate, + which may be different than the hostname (for hosts with multiple + virtual hosts, for example, or because the certificate is for a + load-balanced name). - Use idg/ssl-key/starYYYY for the key for the *.stanford.edu - certificate, where YYYY is the expiration year. + Use ssl-key/starYYYY.stanford.edu for the key for the + *.stanford.edu certificate, where YYYY is the expiration year. (OLD: --ssl-key) - /tivoli-key/ + tivoli-key/ The Tivoli password or backup encryption key for this server. Both the password and the encryption key, if used, are stored in @@ -116,13 +144,13 @@ Object Naming (OLD: --tivoli-key) - In all cases, is the server (or group of servers) on which - the file will be stored, not the server expecting that key material - for authentication. + In all cases, should be a fully-qualified domain name in the + new naming convention. In the old naming convention, .stanford.edu + was omitted, but this adds unnecessary ambiguity. Service-based: - /config/- + config/// A configuration file named that contains some secure information, such as a database password. Ideally, the secure @@ -133,7 +161,7 @@ Object Naming (OLD: --config-) - /db// + db/// Stores the database password for access to the database named . This may be a file containing only the database @@ -142,17 +170,17 @@ Object Naming (OLD: --db-) - /gpg-key/ + gpg-key// Stores the GnuPG private key for a service that needs to do GnuPG signing or encryption. (OLD: --gpg-key) - /password/- + password/// A password for some account, service, keystore, or something - similar that covered by one of the more specific naming + 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. is the service that uses this password and is the thing the password is used for (such as the remote @@ -163,7 +191,7 @@ Object Naming (OLD: --password-) - /properties/ + properties//[/] The properties file for a Java application that contains some secure data (such as SSL key passwords or database passwords). @@ -171,28 +199,37 @@ Object Naming the password and closely-related information, such as database connection information. For anything else, switch to storing the password separately using the password type above and building the - properties file dynamically from the password and a template. + properties file dynamically from the password and a template. The + optional component is for when there are multiple files + stored for a particular service. (OLD: --properties) - /ssl-keystore/ + ssl-keystore//[/] The Java keystore file (containing both public and private key) used by a service for authentication to other services. If a - given service uses more than one, include the purpose in the - part of the name. + given service uses more than one, use the optional + component to distinguish. (OLD: --ssl-keystore) - /ssl-pkcs12/ + ssl-pkcs12//[/] The PKCS#12 file (containing both public and private key) used by a service for authentication to other services. If a given - service uses more than one, include the purpose in the - part of the name. + service uses more than one, use the optional component to + distinguish. (OLD: --ssl-pkcs12) + If there are separate objects for different tiers, should be + left unqualified for production and be qualified with a dash and the + tier for non-production. For example, ssl-keystore/idg/accounts would + be the production keystore for the Accounts application, and + ssl-keystore/idg/accounts-uat would be the keystore for the UAT + version. + We previously stored a wider variety of configuration files before developing a way to dynamically substitute the password into a larger configuration file during deployment. The following file types are -- cgit v1.2.3 From f806961bf9e6be8e07f2e304a3aa9906add2aad6 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Sun, 3 Feb 2013 21:40:12 -0800 Subject: Add another case to the Stanford ssl-key naming convention If there are multiple SSL private keys for the same host-based CN, an application name can be added as an additional component of the name. Change-Id: I06e25359b291a77a7dbca1a7f3db84afb2b16ddd Reviewed-on: https://gerrit.stanford.edu/754 Reviewed-by: Russ Allbery Tested-by: Russ Allbery --- docs/stanford-naming | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/stanford-naming b/docs/stanford-naming index f88d148..aa59f68 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -119,7 +119,7 @@ Object Naming (OLD: --ssh-) - ssl-key/ + ssl-key/[/] Stores the SSL X.509 certificate private key for . Used for Apache, Postfix, LDAP, and similar cases where the certificate @@ -130,6 +130,12 @@ Object Naming virtual hosts, for example, or because the certificate is for a load-balanced name). + An optional component may be added if there are + multiple certificates with the same host name as the CN but with + different private keys. (This may happen if, for example, + multiple services are running on the same FQDN but should have + isolated security contexts.) + Use ssl-key/starYYYY.stanford.edu for the key for the *.stanford.edu certificate, where YYYY is the expiration year. -- cgit v1.2.3 From 3733b1537c987a42e4c3f6b30f4ccfef378e7cfc Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Wed, 13 Feb 2013 12:13:41 -0800 Subject: Add ssl-keypair to Stanford naming policy Used currently by MDM to store both the certificate and the key in the same file for convenience. Change-Id: I38901ac93fe3022c2e00f735a0f995500841d709 Reviewed-on: https://gerrit.stanford.edu/784 Reviewed-by: Russ Allbery Tested-by: Russ Allbery --- docs/stanford-naming | 10 ++++++++++ perl/Wallet/Policy/Stanford.pm | 1 + perl/t/stanford-naming.t | 4 +++- 3 files changed, 14 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/stanford-naming b/docs/stanford-naming index aa59f68..5207c40 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -141,6 +141,16 @@ Object Naming (OLD: --ssl-key) + ssl-keypair/[/] + + Same as ssl-key except that the signed certificate is included in + the same file as the private key. This is used for convenience + with some applications that want to have both the signed + certificate and private key in the same file. + + The meaning of and are the same as for + ssl-key. + tivoli-key/ The Tivoli password or backup encryption key for this server. diff --git a/perl/Wallet/Policy/Stanford.pm b/perl/Wallet/Policy/Stanford.pm index 39bea33..1444d51 100644 --- a/perl/Wallet/Policy/Stanford.pm +++ b/perl/Wallet/Policy/Stanford.pm @@ -69,6 +69,7 @@ our %FILE_TYPE = ( 'ssh-dsa' => { host => 1 }, 'ssh-rsa' => { host => 1 }, 'ssl-key' => { host => 1, extra => 1 }, + 'ssl-keypair' => { host => 1, extra => 1 }, 'ssl-keystore' => { extra => 1 }, 'ssl-pkcs12' => { extra => 1 }, 'tivoli-key' => { host => 1 }, diff --git a/perl/t/stanford-naming.t b/perl/t/stanford-naming.t index 9473ed5..3b9ea60 100755 --- a/perl/t/stanford-naming.t +++ b/perl/t/stanford-naming.t @@ -16,7 +16,7 @@ use 5.008; use strict; use warnings; -use Test::More tests => 97; +use Test::More tests => 99; use lib 't/lib'; use Util; @@ -46,6 +46,8 @@ my @VALID_FILES = qw(htpasswd/example.stanford.edu/web ssh-rsa/example.stanford.edu ssl-key/example.stanford.edu ssl-key/example.stanford.edu/mysql + ssl-keypair/example.stanford.edu + ssl-keypair/example.stanford.edu/mysql tivoli-key/example.stanford.edu config/its-idg/example/foo db/its-idg/example/s_foo -- cgit v1.2.3 From 2fdf8ac3a51bd455ae5cd2a4c0ca98e515bce3d4 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Wed, 27 Feb 2013 15:41:10 -0800 Subject: Add license statements to all textual documentation in docs Change-Id: Id5af9714e3d4f516cf7391c869eff89521e145c5 Reviewed-on: https://gerrit.stanford.edu/849 Reviewed-by: Russ Allbery Tested-by: Russ Allbery --- docs/design | 10 ++++++++++ docs/design-acl | 10 ++++++++++ docs/design-api | 10 ++++++++++ docs/netdb-role-api | 10 ++++++++++ docs/notes | 10 ++++++++++ docs/objects-and-schemes | 10 ++++++++++ docs/setup | 10 ++++++++++ docs/stanford-naming | 10 ++++++++++ 8 files changed, 80 insertions(+) (limited to 'docs') diff --git a/docs/design b/docs/design index f7faa55..4bb5587 100644 --- a/docs/design +++ b/docs/design @@ -369,3 +369,13 @@ Security Considerations operations on an object to allow retrieval of the complete history of an object. Third, all wallet operations are logged to syslog and therefore suitable for archiving, analysis, and forensics. + +License + + Copyright 2007, 2008, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/design-acl b/docs/design-acl index dde3395..424b3c6 100644 --- a/docs/design-acl +++ b/docs/design-acl @@ -79,3 +79,13 @@ ACL Schemes (Not yet implemented.) is the name of an AFS PTS group. Access is granted if the principal of the user is a member of that AFS PTS group. + +License + + Copyright 2006, 2007, 2008, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/design-api b/docs/design-api index 8fa2374..9a36e61 100644 --- a/docs/design-api +++ b/docs/design-api @@ -167,3 +167,13 @@ Registering New Implementations where or is the object type or ACL scheme and is the Perl class which implements that object type or ACL verifier. + +License + + Copyright 2006, 2007, 2008, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/netdb-role-api b/docs/netdb-role-api index 6dbcfa4..c90182a 100644 --- a/docs/netdb-role-api +++ b/docs/netdb-role-api @@ -30,3 +30,13 @@ Wallet Issues We'll need to get a principal registered to use it that can query anything for any node but isn't otherwise authorized to use NetDB. + +License + + Copyright 2006, 2007, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/notes b/docs/notes index 97cc5bd..84a82d1 100644 --- a/docs/notes +++ b/docs/notes @@ -226,3 +226,13 @@ Client Issues There are other approaches, but the other approaches all require changes to the server side as well, whereas this is self-contained in the client and can be more easily dropped when we drop K4. + +License + + Copyright 2006, 2007, 2008, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/objects-and-schemes b/docs/objects-and-schemes index 9d92c7b..57c2f9f 100644 --- a/docs/objects-and-schemes +++ b/docs/objects-and-schemes @@ -88,3 +88,13 @@ ACL Schemes their normal principals. Implemented via Wallet::ACL::NetDB::Root. + +License + + Copyright 2012, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/setup b/docs/setup index b8854fc..670cf57 100644 --- a/docs/setup +++ b/docs/setup @@ -85,3 +85,13 @@ Wallet Configuration acl create command, add the ACL entries that should own that object to that ACL with acl add, and then set that ACL as the owner of the object with the owner command. + +License + + Copyright 2007, 2008, 2010, 2012, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/stanford-naming b/docs/stanford-naming index 5207c40..bdf5027 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -317,3 +317,13 @@ ACL Naming krb5 host/example-dev.stanford.edu@stanford.edu Such an ACL would normally be named service/example. + +License + + Copyright 2008, 2009, 2010, 2011, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. -- cgit v1.2.3 From f6c63bdb2be5ccc0c6133bf87025d37805579005 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Wed, 27 Mar 2013 12:51:46 -0700 Subject: Allow owners of objects to destroy them by default Owners of wallet objects are now allowed to destroy them. In previous versions, a special destroy ACL had to be set and the owner ACL wasn't used for destroy actions, but operational experience at Stanford has shown that letting owners destroy their own objects is a better model. Change-Id: I0e97d7a000e62cf5321add7b44140db6edc6769f Reviewed-on: https://gerrit.stanford.edu/973 Reviewed-by: Russ Allbery Tested-by: Russ Allbery --- NEWS | 5 +++++ client/wallet.pod | 6 +++--- docs/design | 6 +++--- docs/notes | 12 ++++++------ perl/Wallet/Server.pm | 19 ++++++++++--------- perl/t/server.t | 20 ++++++++++++-------- server/keytab-backend | 2 +- server/wallet-backend | 8 ++++---- 8 files changed, 44 insertions(+), 34 deletions(-) (limited to 'docs') diff --git a/NEWS b/NEWS index 0d98220..d236f6a 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,11 @@ wallet 1.0 (unreleased) + Owners of wallet objects are now allowed to destroy them. In previous + versions, a special destroy ACL had to be set and the owner ACL wasn't + used for destroy actions, but operational experience at Stanford has + shown that letting owners destroy their own objects is a better model. + wallet-admin has a new sub-command, upgrade, which upgrades the wallet database to the latest schema version. This command should be run when deploying any new version of the wallet server. diff --git a/client/wallet.pod b/client/wallet.pod index 32d81ad..214a157 100644 --- a/client/wallet.pod +++ b/client/wallet.pod @@ -159,9 +159,9 @@ C and C, which use the C ACL, C, which uses the C ACL, and C, which uses the owner or C ACL depending on whether one is setting or retrieving the comment. If the appropriate ACL is set, it alone is checked to see if the user has access. -Otherwise, C, C, C, C, C, C, -and C access is permitted if the user is authorized by the owner -ACL of the object. +Otherwise, C, C, C, C, C, C, +C, and C access is permitted if the user is authorized +by the owner ACL of the object. Administrators can run any command on any object or ACL except for C and C. For C and C, they must still be authorized by diff --git a/docs/design b/docs/design index 4bb5587..8f4b20d 100644 --- a/docs/design +++ b/docs/design @@ -148,9 +148,9 @@ Server Design * Optional ACLs for get, store, show, destroy, and flag operations. If there is an ACL for get, store, or show, that overrides the - normal permissions of the owner. In the absence of an ACL for - destroy or flag, only wallet administrators can destroy an object or - set flags on that object. This entry would need no special ACLs. + normal permissions of the owner. In the absence of an ACL for flag, + only wallet administrators can set flags on that object. This entry + would need no special ACLs. * Trace fields storing the user, remote host, and timestamp for when this object was last created, stored, and downloaded. diff --git a/docs/notes b/docs/notes index 84a82d1..5a7d3bc 100644 --- a/docs/notes +++ b/docs/notes @@ -46,7 +46,7 @@ Server Issues ACL Management - Supported operations are: get, store, create (possibly triggered by a + Supported operations are: get, store, create (possibly triggered by a get or store of something that didn't already exist), destroy, show, and setting or clearing flags. Each of these need a separate ACL potentially. Not sure if we're going to need separate ACLs for each @@ -62,10 +62,9 @@ Server Issues that returns a default ACL given the object type and name if the object doesn't already exist. - Owner rights provides get, store, and show, but not destroy or setting - or clearing flags (not destroy because it's too destructive and we - don't want it done accidentally). This can be overridden by more - precise ACL settings. So the ACL logic would go like this: + Owner rights provides get, store, show, and destroy, but not setting + or clearing flags. This can be overridden by more precise ACL + settings. So the ACL logic would go like this: * If the user is an administrator and the operation isn't get or store, operation is permitted. @@ -74,7 +73,8 @@ Server Issues that specific ACL, apply that ACL. * If the object exists but with no specific ACL setting and the - operation is one of get, store, or show, apply the owner ACL. + operation is one of get, store, show, or destroy, apply the owner + ACL. * If the object doesn't exist and the action is get, store, or create, punt to a local policy if it exists and see if it returns a diff --git a/perl/Wallet/Server.pm b/perl/Wallet/Server.pm index db53f6c..6d67e17 100644 --- a/perl/Wallet/Server.pm +++ b/perl/Wallet/Server.pm @@ -1,7 +1,7 @@ # Wallet::Server -- Wallet system server implementation. # # Written by Russ Allbery -# Copyright 2007, 2008, 2010, 2011 +# Copyright 2007, 2008, 2010, 2011, 2013 # The Board of Trustees of the Leland Stanford Junior University # # See LICENSE for licensing terms. @@ -301,7 +301,7 @@ sub acl_verify { } elsif ($action ne 'comment') { $id = $object->acl ($action); } - if (! defined ($id) and $action ne 'flags' and $action ne 'destroy') { + if (! defined ($id) and $action ne 'flags') { $id = $object->owner; } unless (defined $id) { @@ -970,9 +970,10 @@ owner as determined by the wallet configuration. Destroys the object identified by TYPE and NAME. This destroys any data that the wallet had saved about the object, may remove the underlying object from other external systems, and destroys the wallet database entry -for the object. To destroy an object, the current user must be authorized -by the ADMIN ACL or the destroy ACL on the object; the owner ACL is not -sufficient. Returns true on success and false on failure. +for the object. To destroy an object, the current user must be a member +of the ADMIN ACL, authorized by the destroy ACL, or authorized by the +owner ACL; however, if the destroy ACL is set, the owner ACL will not be +checked. Returns true on success and false on failure. =item dbh() @@ -981,10 +982,6 @@ mostly for testing; normally, clients should perform all actions through the Wallet::Server object to ensure that authorization and history logging is done properly. -=item schema() - -Returns the DBIx::Class schema object. - =item error() Returns the error of the last failing operation or undef if no operations @@ -1058,6 +1055,10 @@ The owner of an object is permitted to get, store, and show that object, but cannot destroy or set flags on that object without being listed on those ACLs as well. +=item schema() + +Returns the DBIx::Class schema object. + =item show(TYPE, NAME) Returns (as a string) a human-readable representation of the metadata diff --git a/perl/t/server.t b/perl/t/server.t index 8474989..4afda51 100755 --- a/perl/t/server.t +++ b/perl/t/server.t @@ -3,12 +3,12 @@ # Tests for the wallet server API. # # Written by Russ Allbery -# Copyright 2007, 2008, 2010, 2011, 2012 +# Copyright 2007, 2008, 2010, 2011, 2012, 2013 # The Board of Trustees of the Leland Stanford Junior University # # See LICENSE for licensing terms. -use Test::More tests => 381; +use Test::More tests => 382; use POSIX qw(strftime); use Wallet::Admin; @@ -497,10 +497,6 @@ is ($server->create ('base', 'service/test'), undef, ' nor can we create objects'); is ($server->error, "$user1 not authorized to create base:service/test", ' with error'); -is ($server->destroy ('base', 'service/user1'), undef, - ' or destroy objects'); -is ($server->error, "$user1 not authorized to destroy base:service/user1", - ' with error'); is ($server->owner ('base', 'service/user1', 'user2'), undef, ' or set the owner'); is ($server->error, @@ -801,6 +797,12 @@ is ($server->store ('base', 'service/both', 'stuff'), undef, ' or store it'); is ($server->error, 'cannot find base:service/both', ' because it is gone'); +# Switch back to user1 and test destroy. +$server = eval { Wallet::Server->new ($user1, $host) }; +is ($@, '', 'Switching users works'); +is ($server->destroy ('base', 'service/user1'), 1, + 'Destroy of an object we own with no destroy ACLs works'); + # Test default ACLs on object creation. # # Create a default_acl sub that permits $user2 to create service/default with @@ -836,8 +838,10 @@ sub default_owner { } package main; -# We're still user2, so we should now be able to create service/default. Make -# sure we can and that the ACLs all look good. +# Switch back to user2, so we should now be able to create service/default. +# Make sure we can and that the ACLs all look good. +$server = eval { Wallet::Server->new ($user2, $host) }; +is ($@, '', 'Switching users works'); is ($server->create ('base', 'service/default'), undef, 'Creating an object with the default ACL fails'); is ($server->error, "$user2 not authorized to create base:service/default", diff --git a/server/keytab-backend b/server/keytab-backend index e45aba2..b0116c7 100755 --- a/server/keytab-backend +++ b/server/keytab-backend @@ -152,7 +152,7 @@ __END__ =for stopwords keytab-backend keytabs KDC keytab kadmin.local -norandkey ktadd remctld -auth Allbery rekeying +auth Allbery rekeying MERCHANTABILITY NONINFRINGEMENT sublicense =head1 NAME diff --git a/server/wallet-backend b/server/wallet-backend index 9d45982..fc3434e 100755 --- a/server/wallet-backend +++ b/server/wallet-backend @@ -335,7 +335,7 @@ __END__ =for stopwords wallet-backend backend backend-specific remctld ACL acl timestamp getacl setacl metadata keytab keytabs enctypes enctype ktadd KDC Allbery -autocreate +autocreate MERCHANTABILITY NONINFRINGEMENT sublicense =head1 NAME @@ -386,9 +386,9 @@ C and C, which use the C ACL, C, which uses the C ACL, and C, which uses the owner or C ACL depending on whether one is setting or retrieving the comment. If the appropriate ACL is set, it alone is checked to see if the user has access. -Otherwise, C, C, C, C, C, C, -and C access is permitted if the user is authorized by the owner -ACL of the object. +Otherwise, C, C, C, C, C, C, +C, and C access is permitted if the user is authorized +by the owner ACL of the object. Administrators can run any command on any object or ACL except for C and C. For C and C, they must still be authorized by -- cgit v1.2.3