|
Description
|
See comments.
xxxxx@xxxxx.com 2005-1-11 14:49:30 GMT
Below is a scenario to illustrate a simple
version of the reported problem:
path components in all caps are fs roots:
# share -F nfs /EXPORT/fred
# share -F nfs -o sec=krb5 /EXPORT/fred/GINGER
# unshare /EXPORT/fred
# share -F nfs /EXPORT/fred
When a dir is shared, the sec flavors are propagated to
all path components which are also export roots. There
are 2 types of export roots:
REAL : means dir was explicitly shared
PSEUDO: means dir is implicitly shared because it has a shared descendant
In fred's case, authsys ref counts would be incremented for:
/ (pseudo)
/EXPORT (pseudo)
When GINGER is shared, krb5 refcounts are incremented for:
/, /EXPORT, /EXPORT/fred
because they are all ancestor exportroots. fred is a "REAL"
export root because it was explicitly shared. / and /EXPORT
are pseudo exports because they are file system roots which
have at least 1 descendant share (fred, and GINGER).
When fred is unshared, the export root info related to fred is
destroyed because fred is not a file system root. Shared
file system roots which have shared descendants cannot be destroyed
because they maintain the group of pseudonodes required to access
shared descendants.
Later when fred is reshared, fred's flavor info is propagated to its
ancestors, but fred is clueless about flavors of shared descendants
because that flavor info was destroyed when fred was unshared the
first time.
Visible entries (aka pseudofs nodes) are maintained only in exportroots
which are also fs roots (VROOT). Since VROOT export roots simply "morph"
from a real export to a pseudo export when unshared, the visible entries
are retained even across unshare/reshare events.
The proposed design change to cause implicit flavor ref counts (flavors of
shared descendants) to persist across non-VROOT export roots being unshared /
reshared is to record implicit flavor refcounts within each pseudo node.
The info would never be used when enforcing flavors -- the pseudonodes are
simply used as a convenient way to cache flavors in use by descendants across
share/unshare events. The pseudonode flavor ref counts will only be used to
seed a non-VROOT export root's implicitly allowed flavors at share time.
To go back to our example, when fred is reshared, the explicit flavor list
would continue to be propagated to ancestors. The new step provided by this
design change is that the export code would search for an existing pseudo
node the new export root (fred). If found, the flavor ref counts from
fred's pseudo node would be trasferred to fred's exportdata.
It sounds like a larger design change than it actually is because most
of the code is already there. The components of this fix are:
1. add sec flavor ref count array to the pseudonodes (struct exp_visible)
2. during flavor propagation, if the shared dir is *not* VROOT, when
the first VROOT ancestor is encountered, then check to see if a
pseudo node exists for the non-VROOT export. If so, transfer the
pseudo node flavor ref counts to the non-VROOT export.
That's it. None of the flavor enforcement code needs to change. It
will continue to assume that an exportinfo struct contains all
flavor info to access any object shared within its jurisdiction.
|
