[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dazuko-devel] Symlink reporting

From: John Ogness
Subject: Re: [Dazuko-devel] Symlink reporting
Date: Thu, 20 Jan 2005 21:28:15 +0100
User-agent: Mozilla Thunderbird 0.9 (X11/20041114)

John Ogness wrote:
I agree that Dazuko should return the link and not the real name. This can be very easily fixed by adding new names to the end of the alias-list instead of to the beginning.

I have implemented this in CVS for Linux 2.2/2.4 and FreeBSD 4/5. These changes won't make the 2.0.5 release, but you can check it out in CVS.

$ env CVS_RSH="ssh" cvs -z3 \
-d:ext:address@hidden:/cvsroot/dazuko \
co dazuko

For Linux 2.6 this would be quite a tricky challenge. inode_permission() does not provide the dentry of the link, even if a link is accessed. Dazuko currently has no way of knowing that a link was accessed under Linux 2.6.

On Linux 2.6 I guess the way to go is to set up an inode_follow_link callback and report the symlink access from there. Unfortunately, when the inode_permission callback is called, there is no way to know if inode_follow_link was called previously. This means that on Linux 2.6 the dazuko driver would report file accesses thru symlink twice: first the access to the symlink and then the access to the real file.

As you mentioned, I could also hook inode_follow_link(). I don't think we would want to generate an event from this, but Dazuko could be able to cache the link (along with the dereferenced dentry and task struct) so that when an inode_permission() call comes (and it is the same task struct and dentry) then I could assume it is the same call and include the link-dentry to the alias list. Does this sound ugly? ...yes.

With the upcoming DazukoFS this will be much more elegant and reliable. The question is: should I spend development time trying to get these features to work with LSM or should I spend my time working on DazukoFS?

Personally I would like to move away from LSM as soon as possible. Can we survive with LSM in its current form for another 3-6 months?

John Ogness

Dazuko Maintainer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]