Re: Finding symlink information in MAC Framework
jan.gr...@bristol.ac.uk wrote: On Wed, 27 Jul 2011, per...@pluto.rain.com wrote: ... One additional thing that symlinks manage to do is to refer to directories as well as files Yes; I left that aspect out by way of simplification since it did not seem pertinent to the OP's situation. hard links to directories spawn problems such as requiring garbage collection and smarter filesystem descent algorithms, which is another reason they're typically prohibited except in the case where they're created by mkdir. or by mv, when moving a directory within the same physical filesystem. The two biggest problems I'm aware of are: * They create the possibility that the filesystem is no longer a tree but a more general directed graph which may even be cyclic. The possibility of a cyclic graph would indeed require handling in utilities such as find(1) and ls -R, but the only case I've thought of that would need garbage collection -- as opposed to some minor extension of the current reference-counting scheme -- would be detection of cycles that have become disconnected (unreachable from either the root or any currently-open directory). However, I think prohibition of hard-links to directories is not sufficient to prevent the creation of isolated cycles. Consider: $ mkdir -p /tmp/a/b/c/d/e/f/g $ cd /tmp/a/b/c/d/e $ mv /tmp/a/b f/g Unless either mv or the kernel goes to some trouble to detect the subterfuge, this will create an isolated cycle f/g/b/c/d/e/f/... * Where should my .. entry point, if links to me (other than my . entry and my subdirectories' .. entries) appear in more than one directory? FWIW one of the early unix systems I was exposed to permitted the creation of hard links by arbitrary users. Just _one_? I've never heard of any that did _not_ permit that! (AFAIK Posix requires it.) ___ 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
Re: Finding symlink information in MAC Framework
On Wed, 27 Jul 2011, per...@pluto.rain.com wrote: s s...@samu.pl wrote: ... I am trying to compare the owner of the symlink to the owner of what the symlink points to ... At first I was trying to check wheter some user is trying to create such a symlink ... I've always considered the ownership and permissions of a symlink to be an artifact of the implementation, rather than having any real significance. Symlinks did not exist in Bell Labs Unix, at least as of 6th edition. IIUC they were invented at UCB to get around the limitation that a hard link could not cross a physical filesystem boundary (i.e. a mount point); symlinks would not have been needed had the entire logical filesystem been contained on a single, unpartitioned physical device because hard links could have been used instead. One additional thing that symlinks manage to do is to refer to directories as well as files; hard links to directories spawn problems such as requiring garbage collection and smarter filesystem descent algorithms, which is another reason they're typically prohibited except in the case where they're created by mkdir. Getting back to the original problem, suppose you had no mounted filesystems (other than special cases like devfs or /proc), the entire logical filesystem tree being stored on a single device, so that any file on the system could be hard-linked into any directory on the system. How would you detect that some user had created a _hard_ link to some arbitrary file? FWIW one of the early unix systems I was exposed to permitted the creation of hard links by arbitrary users. This led to a denial of service situation whereby the original creators of files could be deprived of inodes in the quota system, and blocks too if they removed one of their files without checking if anyone else had it linked first. It was a multiuser system that hosted undergraduates, so obviously this wasn't just a theoretical problem. -- jan grant, University of Bristol. But not for much longer! Update your address books: j...@ioctl.org http://ioctl.org/jan/ Q: What's yellow and equivalent to the axiom of choice? A: Zorn's lemon. ___ 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
Re: Finding symlink information in MAC Framework
s s...@samu.pl wrote: ... I am trying to compare the owner of the symlink to the owner of what the symlink points to ... At first I was trying to check wheter some user is trying to create such a symlink ... I've always considered the ownership and permissions of a symlink to be an artifact of the implementation, rather than having any real significance. Symlinks did not exist in Bell Labs Unix, at least as of 6th edition. IIUC they were invented at UCB to get around the limitation that a hard link could not cross a physical filesystem boundary (i.e. a mount point); symlinks would not have been needed had the entire logical filesystem been contained on a single, unpartitioned physical device because hard links could have been used instead. A hard link has no ownership or permissions of its own: it is just an additional directory entry pointing to the same inode as the target's original directory entry. (The permissions are stored in the inode, not in the directory entry.) Because the target of a symlink is (in the general case) not in the same physical filesystem as the symlink itself, the symlink has to be stored in its own inode -- and that inode, like any other, has ownership and permission fields which will inevitably contain some pattern of bits -- but it's not clear to me that anything is gained by assigning a meaning to those patterns. Getting back to the original problem, suppose you had no mounted filesystems (other than special cases like devfs or /proc), the entire logical filesystem tree being stored on a single device, so that any file on the system could be hard-linked into any directory on the system. How would you detect that some user had created a _hard_ link to some arbitrary file? ___ 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
Re: Finding symlink information in MAC Framework
On 27 Jul 2011, at 16:57, per...@pluto.rain.com wrote: s s...@samu.pl wrote: ... I am trying to compare the owner of the symlink to the owner of what the symlink points to ... At first I was trying to check wheter some user is trying to create such a symlink ... I've always considered the ownership and permissions of a symlink to be an artifact of the implementation, rather than having any real significance. ... Because the target of a symlink is (in the general case) not in the same physical filesystem as the symlink itself, the symlink has to be stored in its own inode -- and that inode, like any other, has ownership and permission fields which will inevitably contain some pattern of bits -- but it's not clear to me that anything is gained by assigning a meaning to those patterns. One valid (but historically after) reason to have owners on symlinks is the sticky bit on directories: if you want to usefully authorise deletions of symbolic links in /tmp, you really want an owner for them. Getting back to the original problem, suppose you had no mounted filesystems (other than special cases like devfs or /proc), the entire logical filesystem tree being stored on a single device, so that any file on the system could be hard-linked into any directory on the system. How would you detect that some user had created a _hard_ link to some arbitrary file? Right -- I'm not convinced that the suggested design is really coherent in an underlying sense -- which is one reason it doesn't lend itself to implementation. Creating a symlink doesn't involve actual access to the target object at all, since it's really just an object with a string in it that might point at something else. There's also no atomic moment during today's lookup has all the information it needs to check the suggested policy. The closest you could get would be to gather ownership information at the time of readlink, caching it (perhaps in the process label), and later checking it at the time of the later operation. However, as many symlinks can be followed on the way to an underlying object, it sounds like it would require a stack of owners, each of which would have to be compared at the end. 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
Re: Finding symlink information in MAC Framework
On Mon, 25 Jul 2011 10:42:53 +0100 (BST), Robert Watson wrote:
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
Hello,
In general, I am trying to compare the owner of the symlink to the
owner of what the symlink points to, and then do some actions and return
appropriate value, depending on how it will be configured to act. At
first I was trying to check wheter some user is trying to create such a
symlink, but I couldn't find such entry point in MAC Framework.
--
Pozdrawiam,
Jakub 'samu' Szafrański
___
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
Re: Finding symlink information in MAC Framework
On Mon, 25 Jul 2011 10:42:53 +0100 (BST), Robert Watson wrote:
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
Hello,
In general, I am trying to compare the owner of the symlink to the
owner of what the symlink points to, and then do some actions and return
appropriate value, depending on how it will be configured to act. At
first I was trying to check wheter some user is trying to create such a
symlink, but I couldn't find such entry point in MAC Framework.
P.S
My mail client did something messy and sent this reply to a wrong
place, and I would like to apologize for that. I hope that THIS time, it
will be sent to the right place.
--
Pozdrawiam,
Jakub 'samu' Szafrański
___
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
Re: Finding symlink information in MAC Framework
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
Finding symlink information in MAC Framework
Hello everyone,
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?
--
Pozdrawiam,
Jakub 'samu' Szafrański
___
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
