Wallet: a few questions on ACLs (and other animals)

[Russ Allbery]

Jan-Piet Mens <jpmens.dns at gmail.com> writes:

> 1. I'm unsure of the order in which wallet commands are issued. In order
>    to create and then obtain (i.e. `get') a keytab I seem to have to
>    issue the following commands from a client:

>         wallet create keytab nfs/a.net
>         wallet owner keytab nfs/a.net ADMIN
>         wallet -f /tmp/keytab get keytab nfs/a.net

>    If that is so, why do I have to explictly set the owner after it's
>    created?

This is possibly a "Stanfordism", but our normal work flow when creating
new objects in wallet is to create them and then set the owner to some
group entirely unrelated to the person creating the object (since the
creator is in ADMIN but creating an object for someone in some other
department).  So there's no implicit owner so that people remember to
actually set the owner.

> 2. Is there some method of setting an owner on (newly created) objects
>    automatically? The documentation states:

>         With some backends, this will trigger creation of an entry in an
>         external system as well.  The new object will have no ACLs and
>         no owner set, so usually the administrator will want to then set
>         an owner with "owner" so that the object will be usable.

>    Phrased differently, is there a best practice to obtain a host keytab
>    for a machine that is deployed automatically?

Look at the DEFAULT OWNERS section in Wallet::Config.  We use autocreation
as configured there for all host-based principals, using the NetDB roles
as the default ACL.  You should be able to do something similar with your
ACL system.

> 3. The 'comment' command, while documented in wallet(1) isn't
>    implemented in 0.12 (haven't tried latest Git repo yet)

>         $ wallet comment file m1
>         wallet: uknown command comment

Yeah, this is fixed in the latest Git and will be fixed in 1.0.

> 4. doc: wallet(1) says the `owner' command will print the NAME of an
>    ACL. It prints its number.

This is just a bug.  I'll try to fix this.  In general, wallet uses
numeric ACLs in a bunch of places where it should translate them into
names.

> 5. How can I set an object to be read-only? For example, I want to
>    create a `file' object writeable by an administrator but readable by
>    certain principals only.

Don't make those principals owners; instead, put them on a get ACL.  This
is where the separate ACLs are used.  If there is an explicit ACL set
(get, store, show, destroy, flags), it overrides the owner's permissions.
(Unfortunately, currently this means that you have to set the get ACL to
an ACL that includes the administrators if you want them to still be able
to get the object.  That will probably continue to be the case, but will
become easier to do when I implement nested ACLs.)

> 6. getattr/setattr: what are the names of the <attr>ibutes? Are these
>    the attributes mentioned in, say, Wallet::Object::Keytab?

Yes.  Currently, only the attributes enctypes and sync for keytab objects
exist.

>    If I call

>         wallet getattr keytab nfs/a.net enctypes

>    nothing is printed.

By default, keytab objects are not created with any enctype restrictions.
(The enctypes attribute is the forced list of enctypes, and when empty,
means that all standard enctypes as configured on your KDC are used.)

> 7. config: I can specify wallet = {} options in krb5.config. May I
>    specify more than one Wallet server (to implement failover)?

Not currently.

>    Related: Is it possible to configure the wallet servername via a DNS
>    SRV/TXT record?  (Haven't checked the source code -- sorry.)

Not currently.  It's a little tricky to use a SRV record for this since
wallet doesn't have its own port (it just uses remctl), and normally SRV
records are tied to services with unique port assignments.  I could just
make up some TXT record convention, but I feel weird about that.

There are also security issues with trusting DNS if you don't have DNSSEC
configured.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>