I am trying to implement a authorization plug-in and would like to apply my rules only if the file system exists on any physically attached device (hard disk, usb, cd/dvd, etc). Would like to bypass these rules for data store that is connected using network to optimize the authorization process(I am looking into file contents for authorization decisions). In that case, is it sufficient to check MNT_LOCAL ?
Is it a guideline for kauth plugin to check vfs_authopaque( ) and not do anything if the file system is mounted with auth_opaque flag ?
----- Original Message ----
> In kernel extension how do I find out whether a given file object
> indicated by vnode_t is locally mounted(hfs, ufs, cd9660) or a
> network volume (nfs, smb etc) ?
It's doubtful that this information will be useful to you, since it's
not likely to have exactly the semantics you are expecting;
nevertheless, here's the answer specifically to the question you
asked, vs. the question you probably should have asked instead, since
you haven't told us _why_ you want to know:
mount_t mp;
uint64_t flags;
if ((mp = vnode_mount(vp)) != NULL) {
flags = vfs_flags(mp);
if (flags & MNT_LOCAL) {
/* Do
stuff for local FSs... */
} else {
/* Do stuff for remote FSs... */
}
} else {
/*
* This vnode is horked; I probably grabbed it when I shouldn't
* have, or I held onto it too long, or I screwed up my references
* to it; anyway, it's my fault it's horked...
*/
}
Note that "local" is probably not what you expect it to be; for
example, an FS implemented as a client of a user space process is
likely to be considered as "remote", even if it's
implemented by going
to user space and operating against a file stored on a local FS in
user space, rather than communicating across a network. In this sense
"local" pretty much means "in my address space, won't go away
asynchronously to some form of notification, obeys all lock semantics,
etc.".
For example, if you are using this for authorizations, or anything
like that, you are more likely to want to know if authorization is
opaque (handled by the FS, some other process, the remote server,
whatever) or non-opaque (handled at the VFS layer so that the file
system doesn't have to handle it, with the idea that the security
model can safely be locally enforced), e.g. the results of
vfs_authopaque(mp), instead of whether or not it's "local".
If you need more information, then it'd
probably help if you told us
how you plan to use it - i.e. you should tell us what problem you
think will be solved by getting the answer to this question, and
whether or not that's the right way to go about solving it or not, and
if it isn't, someone can give you a list of alternate approaches to
tackling the problem...
-- Terry