linux-kernel - Re: Thinking outside the box on file systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <A631EFDE-354D-498E-980E-2B785517AC51@mac.com>
Date:	Wed, 15 Aug 2007 13:22:43 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Marc Perkel <mperkel@...oo.com>
Cc:	Valdis.Kletnieks@...edu, Michael Tharp <gxti@...tiallystapled.com>,
	alan <alan@...eserver.org>,
	LKML Kernel <linux-kernel@...r.kernel.org>,
	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
Subject: Re: Thinking outside the box on file systems

On Aug 15, 2007, at 13:09:31, Marc Perkel wrote:
> The idea is that people have permissions - not files.  By people I  
> mean users, groups, managers, applications
> etc. One might even specify that there are no permission  
> restrictions at all. Part of the process would be that the kernel  
> load what code it will use for the permission system. It might even  
> be a little perl script you write.
>
> Also - you aren't even giving permission to access files. It's  
> permission to access name patterns. One could apply REGEX masks to  
> names to determine permissions. So if you have permission to the  
> name you have permission to the file.

Please excuse me, I'm going to go stand over in the corner for a minute.

*hahahahahaa hahahahahaaa hahaa hoo hee snicker sniff*

*wanders back into the conversation*

Sorry about that, pardon me.

I suspect you will find it somewhat hard to convince *anybody* on  
this list to put either a regex engine or a Perl interpreter into the  
kernel.  I doubt you could even get a simple shell-style pattern  
matcher in.  First of all, both of the former chew up enormous gobs  
of stack space *AND* they're NP-complete.  You just can't do such  
matching even in polynomial time, let alone something that scales  
appropriately for an OS kernel like, say, O(log(n)).

Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/