Weekly Edition Return to the Kernel page |
securityfs
Some observers might well believe that the kernel has accumulated plenty of
special-purpose virtual filesystems. Even so, 2.6.14 will include yet
another one: securityfs. This filesystem is meant to be used by security
modules, some of which were otherwise creating their own filesystems; it
should be mounted on /sys/kernel/security. Securityfs thus looks,
from user space, like part of sysfs, but it is a distinct entity.
The API for securityfs is quite simple - it only exports three functions (defined in <linux/security.h>). The usual first step will be to create a directory specific to the security module at hand with:
struct dentry *securityfs_create_dir(const char *name,
struct dentry *parent);
If parent is NULL, the directory will be created in the root of the filesystem. That directory can be populated with files using:
struct dentry *securityfs_create_file(const char *name,
mode_t mode,
struct dentry *parent,
void *data,
struct file_operations *fops);
Here, name is the name of the file, mode is the permissions the file will have, parent is the containing directory (or NULL for the filesystem root), data is a private data pointer, and fops is a file_operations structure containing the methods which actually implement the file. The calling module must provide operations which make the file behave as desired. Securityfs differs from sysfs in this regard; it makes no attempt to hide the low-level file implementation. As a result, security modules can do ill-advised things like creating highly complex files, providing ioctl() operations, and more. Most modules, however, will simply want to provide straightforward open(), read(), and (maybe) write() methods and be done with it. All of these files and directories should be cleaned up when the module is unloaded. The same function is used for both files and directories:
void securityfs_remove(struct dentry *dentry);
There is no automatic cleanup of files performed, so this step is mandatory. Those wanting to see an example of securityfs in action can look at this patch in 2.6.14 which causes the seclvl module to use it. (Log in to post comments)
securityfs Posted Sep 29, 2005 18:11 UTC (Thu) by tkreagan (subscriber, #4548) [Link] Can someone explain the necessity of this new filesystem? It seems a little weird to me (and this is probably just my ignorance) that we are adding a filesystem with no built-in implementation, instead with overloaded functions from the modules, but we can't add ReiserFS because it does similar things.
I certainly don't agree with letting ReiserFS add overloaded calls to implement its functionality, but why are we letting the security sub-systems do the same thing? What do they need that isn't already there?
--tkr
securityfs Posted Sep 29, 2005 20:27 UTC (Thu) by anonymous21 (guest, #30106) [Link] Securityfs is a pseudo-filesystem where you can only have files and directories _in memory_ to configure those security modules. Securityfs is built on top of the VFS and is only a few lines long.
securityfs Posted Sep 30, 2005 6:38 UTC (Fri) by astrand (subscriber, #4908) [Link] The kernel patch might just be a few lines long, but every new file system will mean that extra work needs to be done *outside* the kernel: Every distribution needs a new line to /etc/fstab, modifications to rc.sysinit (or similiar). The output from "mount" will be even harder to read, and all users will se *yet* another strange directory when browsing /.
As a side note, I don't really like that the desktop environments are moving away from / as the "root" and introducing concepts like "My Computer" instead, but if / is getting filled up with strange directores...
Can someone explain to me why it's impossible to create a tree with sysfs and securityfs semantics below /proc/sysfs and /proc/securityfs?
/proc was abused Posted Sep 30, 2005 11:04 UTC (Fri) by alex (subscriber, #1355) [Link] Its not impossible. However all this stuff was moved out of /proc for a reason. /proc is meant to be about processes, not the innards of how your system works. However it has been historically abused as the dumping ground for any number of random interfaces to kernel behaviour.
/proc was abused Posted Sep 30, 2005 11:34 UTC (Fri) by astrand (subscriber, #4908) [Link] But /proc as a generic kernel interface has worked very good. I've never heard complaints about that /proc contains stuff that's not about processes.
And even if the intention is to move things out of /proc so that it's only about processes, why is it not enough with *one* additional kernel interface?
/proc was abused Posted Sep 30, 2005 11:54 UTC (Fri) by alex (subscriber, #1355) [Link] Well you've only really got /proc, /dev and /sys which covers the three different paradigms. Does it really matter how much is in / anyway? After all I spend most of my time in /home/alex which is which I can organise however I want.
/proc was abused Posted Sep 30, 2005 12:00 UTC (Fri) by astrand (subscriber, #4908) [Link] >Does it really matter how much is in / anyway?
Yes. Sometimes you need to browse to /tmp, /media/cdrom, /net/import/mirrors and stuff like that.
securityfs Posted Oct 6, 2005 13:33 UTC (Thu) by efexis (guest, #26355) [Link] All these directories in the root put off the not-so-tech-savvy desktop user. I'd go for creating a /system, and moving /proc, /sys, and yeah, even /dev into it. Whilst I have no problem putting anything anywhere on the filesystem, there's no denying that in it's currently layout, it's incredibly ugly.
Yes I know the work involved, which is why I've not done it :-p
securityfs Posted Oct 6, 2005 17:42 UTC (Thu) by peschmae (guest, #32292) [Link] Then tell me what your not-so-tech-savvy desktop user has lost in /
Well, right, once in a while they get lost - but on their random walk down the file system they might just as well lose themselves in your /system directory as in /
securityfs Posted Oct 9, 2005 10:10 UTC (Sun) by nicolas@jungers (subscriber, #7579) [Link] Then tell me what your not-so-tech-savvy desktop user has lost in /I think that the lambda user expect to be lost in /system but to clearly understand what's on _his_ computer. The difference is the isolation of the acknowledged unmastered stuffs in one conceptually mastered place. Most l-users I know understand perfectly well the concept of root (everything on _their_ computer) in regard of the concept of home (all my personal stuffs and the personal stuffs of anybody I allow to use my computer).
securityfs Posted Oct 11, 2005 4:06 UTC (Tue) by efexis (guest, #26355) [Link] um... what??? Taking that to the extreme would be to say that wholecities may as well be built like mazes, without signposts or maps. Sure people might get lost, but as they are able to wonder into real mazes and get lost should they decide to, they may as well get lost outside them too. As I said, taken to the extreme, to illustrate a point. You could think of better closer to real-world examples if you put their mind to it. Maybe the electrics or pipes, and the meters they connect to that run through office blocks? Electricions/plumbers can get to them if they need to repair or make modifications to them, they have the knowledge, the tools. But if you just want to work in the office, and especially to employ others to, you want the stuff that's not needed out of the way. It's consciously/subconsciously processed everytime it's seen, clouding the mind, and creating a greater feeling of unfamiliarity. How can that possibly be a good thing?
securityfs Posted Oct 28, 2005 14:50 UTC (Fri) by Xires (guest, #33435) [Link] http://www.linuxbase.org/spec/I didn't know who to reply to; everyone seemed to be complaining. I personally understand the desire to keep things as organized as possible(atleast in respect to a filesystem). On the other hand, there is already so much disarray that I fail to see where it really matters. Originally, /etc was supposed to contain system-wide configuration details necessary for getting the system up and functional and for allowing it to maintain functionality in runlevel 1. Now it seems that it's common practice to just drop every configuration file known there with little to no additional organization. With this de facto standard in effect, why bother organizing / itself? Furthermore, with securityfs residing inside of /sys, I see no more disarray in the general filesystem scheme than what was already there. If you are mounting /sys, it's already there taking up space in /..so why complain about entries in /?
securityfs Posted Dec 4, 2005 14:44 UTC (Sun) by anonymous21 (guest, #30106) [Link] You can mount any filesystem anywhere you like it! Nothing is stopping youfrom doing something like this (except that some programs might stop working):
mkdir /system
And so on...
|
Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds
Powered by Rackspace Managed Hosting.