2002-11-05 15:44:57

by Olaf Dietsche

[permalink] [raw]
Subject: [PATCH] 2.5.46: access permission filesystem

This *untested* patch adds a new permission managing file system.
Furthermore, it adds two modules, which make use of this file system.

One module allows granting capabilities based on user-/groupid. The
second module allows to grant access to lower numbered ports based on
user-/groupid, too.

Changes:
- updated to 2.5.46

This patch is available at:
<http://home.t-online.de/home/olaf.dietsche/linux/accessfs/>

Regards, Olaf.


2002-11-10 01:26:52

by Ben Clifford

[permalink] [raw]
Subject: Re: [PATCH] 2.5.46: access permission filesystem

On Tue, 5 Nov 2002, Olaf Dietsche wrote:

> This *untested* patch adds a new permission managing file system.
> Furthermore, it adds two modules, which make use of this file system.

Hi.

I've just applied this to 2.5.46, and I'm building accessfs as modules.

During boot (my scripts do a probe for the accessfs modules), I get:

====

Debug: sleeping function called from illegal context at mm/slab.c:1304
Call Trace:
[<c0115fa6>] __might_sleep+0x56/0x60
[<c0130da1>] kmem_flagcheck+0x21/0x50
[<d0963319>] .rodata.str1.1+0xc9/0xd8 [userports]
[<c013169b>] kmalloc+0x4b/0x130
[<d096331c>] .rodata.str1.1+0xcc/0xd8 [userports]
[<c0130da1>] kmem_flagcheck+0x21/0x50
[<d0963319>] .rodata.str1.1+0xc9/0xd8 [userports]
[<d0961320>] accessfs_rootdir+0x0/0x34 [accessfs]
[<d0960409>] accessfs_node_init+0x29/0xc0 [accessfs]
[<d0961320>] accessfs_rootdir+0x0/0x34 [accessfs]
[<d0961320>] accessfs_rootdir+0x0/0x34 [accessfs]
[<d096331c>] .rodata.str1.1+0xcc/0xd8 [userports]
[<d0960554>] accessfs_mkdir+0x44/0x80 [accessfs]
[<d0961320>] accessfs_rootdir+0x0/0x34 [accessfs]
[<d0963319>] .rodata.str1.1+0xc9/0xd8 [userports]
[<d0963319>] .rodata.str1.1+0xc9/0xd8 [userports]
[<d0961320>] accessfs_rootdir+0x0/0x34 [accessfs]
[<d0960611>] accessfs_make_dirpath_Rf12799b4+0x81/0xd0 [accessfs]
[<d0961320>] accessfs_rootdir+0x0/0x34 [accessfs]
[<d0963319>] .rodata.str1.1+0xc9/0xd8 [userports]
[<d096331c>] .rodata.str1.1+0xcc/0xd8 [userports]
[<d0961320>] accessfs_rootdir+0x0/0x34 [accessfs]
[<d0963111>] init_module+0x11/0xe0 [userports]
[<d0963319>] .rodata.str1.1+0xc9/0xd8 [userports]
[<d0963060>] accessfs_ip_prot_sock+0x0/0x50 [userports]
[<c01195b5>] sys_init_module+0x535/0x620
[<d0963404>] .kmodtab+0x0/0xc [userports]
[<d0963060>] accessfs_ip_prot_sock+0x0/0x50 [userports]
[<c0108bbf>] syscall_call+0x7/0xb

There is already a security framework initialized, register_security
failed.

====

The proc/access/net/ip/bind ports appear ok and I can change permissions
on them. (although I haven't tested to see if their permissions actually
have effect).

I also get

Debug: sleeping function called from illegal context at mm/slab.c:1304
Call Trace:
[<c0115fa6>] __might_sleep+0x56/0x60
[<c0130da1>] kmem_flagcheck+0x21/0x50
[<c0131585>] kmem_cache_alloc+0x15/0xe0
[<c028fca0>] ip_local_deliver_finish+0x0/0x150
[<c02a925f>] tcp_v4_checksum_init+0x7f/0x110
[<c0131b10>] kfree+0x1d0/0x220
[<c0155050>] alloc_inode+0x30/0x170
[<c0155a75>] get_new_inode_fast+0x15/0xd0
[<c012c6e6>] file_read_actor+0x86/0x100
[<c0155e92>] iget_locked+0xa2/0xb0
[<c01315d9>] kmem_cache_alloc+0x69/0xe0
[<d0961340>] accessfs_rootdir+0x20/0x34 [accessfs]
[<d09602a2>] accessfs_lookup+0x42/0xa0 [accessfs]
[<c0154349>] d_alloc+0x19/0x180
[<c014ab9a>] real_lookup+0x5a/0xe0
[<c014ae50>] do_lookup+0xb0/0x200
[<c012cde5>] filemap_nopage+0x115/0x270
[<c0109526>] apic_timer_interrupt+0x1a/0x20
[<c014b54b>] link_path_walk+0x5ab/0x8f0
[<c014a8ae>] getname+0x5e/0xa0
[<c014bc84>] __user_walk+0x24/0x40
[<c0147964>] vfs_lstat+0x14/0x50
[<c0147e91>] sys_lstat64+0x11/0x30
[<c0113560>] do_page_fault+0x0/0x465
[<c01095a1>] error_code+0x2d/0x38
[<c0108bbf>] syscall_call+0x7/0xb

followed by:

Debug: sleeping function called from illegal context at mm/slab.c:1304
Call Trace:
[<c0115fa6>] __might_sleep+0x56/0x60
[<c0130da1>] kmem_flagcheck+0x21/0x50
[<d09a63f5>] .rodata.str1.1+0x1e5/0x1f8 [usercaps]
[<c013169b>] kmalloc+0x4b/0x130
[<c0129d79>] do_no_page+0x39/0x2b0
[<d09a69c0>] caps+0x0/0x160 [usercaps]
[<c0130da1>] kmem_flagcheck+0x21/0x50
[<d09a63f5>] .rodata.str1.1+0x1e5/0x1f8 [usercaps]
[<d09a63fb>] .rodata.str1.1+0x1eb/0x1f8 [usercaps]
[<d0960409>] accessfs_node_init+0x29/0xc0 [accessfs]
[<d09a63f5>] .rodata.str1.1+0x1e5/0x1f8 [usercaps]
[<d09a63fb>] .rodata.str1.1+0x1eb/0x1f8 [usercaps]
[<d09a69c0>] caps+0x0/0x160 [usercaps]
[<d09604f7>] accessfs_mknod+0x57/0x70 [accessfs]
[<d09a63f5>] .rodata.str1.1+0x1e5/0x1f8 [usercaps]
[<d09a69c0>] caps+0x0/0x160 [usercaps]
[<d09a6190>] init_module+0x70/0xc0 [usercaps]
[<d09a63f5>] .rodata.str1.1+0x1e5/0x1f8 [usercaps]
[<d09a69c0>] caps+0x0/0x160 [usercaps]
[<c01195b5>] sys_init_module+0x535/0x620
[<d09a64e4>] .kmodtab+0x0/0xc [usercaps]
[<d09a6060>] accessfs_capable+0x0/0x40 [usercaps]
[<c0108bbf>] syscall_call+0x7/0xb

There is already a security framework initialized, register_security
failed.

The directory /proc/access/capabilities appears, but it has no contents.

Ben

--
Ben Clifford [email protected] GPG: 30F06950
http://www.hawaga.org.uk/ben/

2002-11-11 00:04:36

by Ben Clifford

[permalink] [raw]
Subject: Re: [PATCH] 2.5.46: access permission filesystem

On Sun, 10 Nov 2002, Olaf Dietsche wrote:

> You must build CONFIG_SECURITY_CAPABILITIES as a module or disable it
> for usercaps to work. Usercaps employ LSM and is built as a security
> module. This means, until there's a way to stack lsm security modules,
> there must be no other security module loaded.

I've switched that option to 'm' rather than 'y', and the accessfs
capabilities module now seems to give me all the capability files under
/proc/access.

I still get those stack traces, though...

Ben

--
Ben Clifford [email protected] GPG: 30F06950
http://www.hawaga.org.uk/ben/


Attachments:
.config (24.56 kB)

2002-11-11 01:51:04

by Olaf Dietsche

[permalink] [raw]
Subject: Re: [PATCH] 2.5.46: access permission filesystem

Ben Clifford <[email protected]> writes:

> I still get those stack traces, though...

I retested with CONFIG_PREEMPT=y and now I get those stack traces,
too. So, it seems my code is not preempt safe.

Regards, Olaf.

2002-11-11 02:20:52

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH] 2.5.46: access permission filesystem

Olaf Dietsche wrote:
>
> Ben Clifford <[email protected]> writes:
>
> > I still get those stack traces, though...
>
> I retested with CONFIG_PREEMPT=y and now I get those stack traces,
> too. So, it seems my code is not preempt safe.
>

It's not that your code is unsafe with preemption. It's just that
CONFIG_PREEMPT=y turns on the debugging infrastructure which allows
us to detect things like calling kmalloc(GFP_KERNEL) inside spinlock.

+static int accessfs_node_init(struct accessfs_direntry *parent, struct accessfs_entry *de, const char *name, size_t len, struct access_attr *attr, mode_t mode
+{
+ static unsigned long ino = 1;
+ de->name = kmalloc(len + 1, GFP_KERNEL);
+ ...
+
+static int accessfs_mknod(struct accessfs_direntry *dir, const char *name, struct access_attr *attr)
+{
+ ...
+ spin_lock(&accessfs_lock);
+ accessfs_node_init(dir, pe, name, strlen(name), attr, S_IFREG | attr->mo