On Fri, 15 Jul 2011, s wrote:
I am trying to get some information related to the symlink which is being
accessed by the user in MAC Framework. Currently I managed to get the
uid/gid of the owner of the symlink that is being read, but now I need to
get the same information about the target, that the symlink points to.
static int samplemac_vnode_check_link (struct ucred *cred, struct vnode *vp,
struct label *vplabel)
{
int error;
struct vattr vap;
error = VOP_GETATTR(vp, &vap, cred);
if (error)
return (1);
if(vap.va_uid != 0) {
log(LOG_NOTICE, "stub_vnode_check_readlink: %i, gid: %i\n",
vap.va_uid, vap.va_gid);
return (0);
}
return (0);
}
And I have no idea how could I do that. Where should I look for that info?
And what way would be the fastest?
Hi Jakub:
Could you say a bit more about what you're trying to accomplish? The reason
it's hard to express what you're trying to do (inspect the target of a symlink
during a read of the symlink) is that it's not really a coherent concept in
terms of kernel implementation. At the point where the access control check
on readlink is occuring, the string hasn't yet been read from the link, and
even if it had, you couldn't look up the target object as you're already
holding locks relating to lookup and read of the symlink itself. Even if you
could, there's also a risk of recursion: the symlink could point straight back
to where you are, etc. The readlink check is mid-lookup and triggering an
entirely fresh lookup from there might be quite awkward for a number of such
reasons.
In general, however, this is not an issue for the policies we've encountered
thus far: they almost all care only about authorising path segment lookups (in
which case readlink is just another segment in evaluation), or absolute paths
to objects reconstructed during the actual operation on the target object,
etc. Hence my wondering what you're trying to accomplish -- the first
question, really, is "is what you're trying to express actually safely
expressible in a fine-grained, multiprocessing kernel?"
Robert
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
