Re: [TOMOYO 5/9] Memory and pathname management functions.
On 6/21/07, Pavel Machek <[EMAIL PROTECTED]> wrote: > >> It's really not worth getting bothered by. Truth is, big > >> giant > >> pathnames break lots of stuff already, both kernel and > >> userspace. > > > >> Just look in /proc for some nice juicy kernel breakage: > >> cwd, exe, fd/*, maps, mounts, mountstats, root, smaps > > > >Well, but we should be fixing that, not adding more. And /proc is > >info-only, while this is security related code. > > Security tools read from /proc, so /proc is security-related. If some tool relies on pathnames in /proc, that tool is broken... as is /proc. We should be fixing that. Running TOMOYO or AppArmor fixes the bug. :-) You can't get long paths that break /proc if you are running either. Therefore, one of those is required. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
On 6/21/07, Pavel Machek [EMAIL PROTECTED] wrote: It's really not worth getting bothered by. Truth is, big giant pathnames break lots of stuff already, both kernel and userspace. Just look in /proc for some nice juicy kernel breakage: cwd, exe, fd/*, maps, mounts, mountstats, root, smaps Well, but we should be fixing that, not adding more. And /proc is info-only, while this is security related code. Security tools read from /proc, so /proc is security-related. If some tool relies on pathnames in /proc, that tool is broken... as is /proc. We should be fixing that. Running TOMOYO or AppArmor fixes the bug. :-) You can't get long paths that break /proc if you are running either. Therefore, one of those is required. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Hi! > >> It's really not worth getting bothered by. Truth is, big > >> giant > >> pathnames break lots of stuff already, both kernel and > >> userspace. > > > >> Just look in /proc for some nice juicy kernel breakage: > >> cwd, exe, fd/*, maps, mounts, mountstats, root, smaps > > > >Well, but we should be fixing that, not adding more. And /proc is > >info-only, while this is security related code. > > Security tools read from /proc, so /proc is security-related. If some tool relies on pathnames in /proc, that tool is broken... as is /proc. We should be fixing that. > The limit imposed by TOMOYO (or AppArmor) is fine, > despite being security-related. It just needs to fail in It is not "fine", but maybe it will not get us a bugtraq posting. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Hi! It's really not worth getting bothered by. Truth is, big giant pathnames break lots of stuff already, both kernel and userspace. Just look in /proc for some nice juicy kernel breakage: cwd, exe, fd/*, maps, mounts, mountstats, root, smaps Well, but we should be fixing that, not adding more. And /proc is info-only, while this is security related code. Security tools read from /proc, so /proc is security-related. If some tool relies on pathnames in /proc, that tool is broken... as is /proc. We should be fixing that. The limit imposed by TOMOYO (or AppArmor) is fine, despite being security-related. It just needs to fail in It is not fine, but maybe it will not get us a bugtraq posting. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
On 6/15/07, Pavel Machek <[EMAIL PROTECTED]> wrote: [Albert Cahalan] > It's really not worth getting bothered by. Truth is, big > giant > pathnames break lots of stuff already, both kernel and > userspace. > Just look in /proc for some nice juicy kernel breakage: > cwd, exe, fd/*, maps, mounts, mountstats, root, smaps Well, but we should be fixing that, not adding more. And /proc is info-only, while this is security related code. Security tools read from /proc, so /proc is security-related. The limit imposed by TOMOYO (or AppArmor) is fine, despite being security-related. It just needs to fail in the safe direction: access denied. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
On 6/15/07, Pavel Machek [EMAIL PROTECTED] wrote: [Albert Cahalan] It's really not worth getting bothered by. Truth is, big giant pathnames break lots of stuff already, both kernel and userspace. Just look in /proc for some nice juicy kernel breakage: cwd, exe, fd/*, maps, mounts, mountstats, root, smaps Well, but we should be fixing that, not adding more. And /proc is info-only, while this is security related code. Security tools read from /proc, so /proc is security-related. The limit imposed by TOMOYO (or AppArmor) is fine, despite being security-related. It just needs to fail in the safe direction: access denied. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Hi! > >>We limit the maximum length of any string data (such as > >>domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN > >>(which is 4000) bytes to fit within a single page. > >> > >>Userland programs can obtain the amount of RAM > >>currently > >>used by TOMOYO from /proc interface. > > > >Same NACK for this as for AppArmor, on exactly the same > >grounds. > >Please stop wasting your time on pathname-based > >non-solutions. > > This issue is a very very small wart on an otherwise > fine idea. > It's really not worth getting bothered by. Truth is, big > giant > pathnames break lots of stuff already, both kernel and > userspace. > Just look in /proc for some nice juicy kernel breakage: > cwd, exe, fd/*, maps, mounts, mountstats, root, smaps Well, but we should be fixing that, not adding more. And /proc is info-only, while this is security related code. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Christoph Hellwig writes: On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: We limit the maximum length of any string data (such as domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page. Userland programs can obtain the amount of RAM currently used by TOMOYO from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. This issue is a very very small wart on an otherwise fine idea. It's really not worth getting bothered by. Truth is, big giant pathnames break lots of stuff already, both kernel and userspace. Just look in /proc for some nice juicy kernel breakage: cwd, exe, fd/*, maps, mounts, mountstats, root, smaps So, is that a NACK for the /proc filesystem too? :-) We even limit filenames to 255 chars; just the other day a Russian guy was complaining that his monstrous filenames on a vfat filesystem could not be represented in UTF-8 mode. Both TOMOYO and AppArmor are good ideas. At minimum, one of them ought to be accepted. My preference would be TOMOYO, having origins untainted by Novell's Microsoft dealings. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Christoph Hellwig writes: On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: We limit the maximum length of any string data (such as domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page. Userland programs can obtain the amount of RAM currently used by TOMOYO from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. This issue is a very very small wart on an otherwise fine idea. It's really not worth getting bothered by. Truth is, big giant pathnames break lots of stuff already, both kernel and userspace. Just look in /proc for some nice juicy kernel breakage: cwd, exe, fd/*, maps, mounts, mountstats, root, smaps So, is that a NACK for the /proc filesystem too? :-) We even limit filenames to 255 chars; just the other day a Russian guy was complaining that his monstrous filenames on a vfat filesystem could not be represented in UTF-8 mode. Both TOMOYO and AppArmor are good ideas. At minimum, one of them ought to be accepted. My preference would be TOMOYO, having origins untainted by Novell's Microsoft dealings. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Hi! We limit the maximum length of any string data (such as domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page. Userland programs can obtain the amount of RAM currently used by TOMOYO from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. This issue is a very very small wart on an otherwise fine idea. It's really not worth getting bothered by. Truth is, big giant pathnames break lots of stuff already, both kernel and userspace. Just look in /proc for some nice juicy kernel breakage: cwd, exe, fd/*, maps, mounts, mountstats, root, smaps Well, but we should be fixing that, not adding more. And /proc is info-only, while this is security related code. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Christoph Hellwig wrote: On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: We limit the maximum length of any string data (such as domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page. Userland programs can obtain the amount of RAM currently used by TOMOYO from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. TOMOYO Linux is a pathname-based MAC, that is true. But what that patch aimed for was sharing the idea of having Linux kernel to keep "process invocation history" information for each process. In that sense, TOMOYO Linux is just a sample implementation. Please take a look at the following message: http://lkml.org/lkml/2007/6/13/58 Best regards, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: > We limit the maximum length of any string data (such as domainname and > pathnames) > to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single > page. > > Userland programs can obtain the amount of RAM currently used by TOMOYO > from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TOMOYO 5/9] Memory and pathname management functions.
We limit the maximum length of any string data (such as domainname and
pathnames)
to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page.
Userland programs can obtain the amount of RAM currently used by TOMOYO from
/proc interface.
Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
security/tomoyo/include/realpath.h | 46 +
security/tomoyo/realpath.c | 445
+
2 files changed, 491 insertions(+)
diff -ubBpErN linux-2.6.21.5/security/tomoyo/include/realpath.h
linux-2.6.21.5-tomoyo/security/tomoyo/include/realpath.h
--- linux-2.6.21.5/security/tomoyo/include/realpath.h 1970-01-01
09:00:00.0 +0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/include/realpath.h2007-06-05
00:00:00.0 +0900
@@ -0,0 +1,46 @@
+/*
+ * security/tomoyo/include/realpath.h
+ *
+ * Get the canonicalized absolute pathnames. The basis for TOMOYO.
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ *
+ */
+
+#ifndef _TOMOYO_REALPATH_H
+#define _TOMOYO_REALPATH_H
+
+struct path_info;
+
+/* Returns realpath(3) of the given pathname but ignores chroot'ed root. */
+int tomoyo_realpath_from_dentry2(struct dentry *dentry,
+ struct vfsmount *mnt,
+ char *newname,
+ int newname_len);
+
+/* Returns realpath(3) of the given pathname but ignores chroot'ed root. */
+/* These functions use tomoyo_alloc(), so caller must tomoyo_free() */
+/* if these functions didn't return NULL. */
+char *tomoyo_realpath(const char *pathname);
+char *tomoyo_realpath_nofollow(const char *pathname);
+char *tomoyo_realpath_from_dentry(struct dentry *dentry, struct vfsmount *mnt);
+
+/* Allocate memory for structures. */
+/* The RAM is chunked, so NEVER try to kfree() the returned pointer. */
+void *tomoyo_alloc_element(const unsigned int size);
+
+/* Get used RAM size for tomoyo_alloc_elements(). */
+unsigned int tomoyo_get_memory_used_for_elements(void);
+
+/* Keep the given name on the RAM. */
+/* The RAM is shared, so NEVER try to modify or kfree() the returned name. */
+const struct path_info *tomoyo_save_name(const char *name);
+
+/* Get used RAM size for tomoyo_save_name(). */
+unsigned int tomoyo_get_memory_used_for_save_name(void);
+
+unsigned int tomoyo_get_memory_used_for_dynamic(void);
+
+#endif
diff -ubBpErN linux-2.6.21.5/security/tomoyo/realpath.c
linux-2.6.21.5-tomoyo/security/tomoyo/realpath.c
--- linux-2.6.21.5/security/tomoyo/realpath.c 1970-01-01 09:00:00.0
+0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/realpath.c2007-06-14
15:06:37.0 +0900
@@ -0,0 +1,445 @@
+/*
+ * security/tomoyo/realpath.c
+ *
+ * Get the canonicalized absolute pathnames.
+ * The basis for TOMOYO Linux.
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "realpath.h"
+#include "tomoyo.h"
+
+extern int sbin_init_started;
+
+/* realpath handler */
+
+/*
+ * tomoyo_get_absolute_path - return the path of a dentry but ignores
chroot'ed root.
+ * @dentry: dentry to report
+ * @vfsmnt: vfsmnt to which the dentry belongs
+ * @buffer: buffer to return value in
+ * @buflen: buffer length
+ *
+ * Caller holds the dcache_lock.
+ * Based on __d_path() in fs/dcache.c
+ *
+ * If dentry is a directory, trailing '/' is appended.
+ * Characters other than ' ' < c < 127 are converted to \ooo style octal
string.
+ * Character \ is converted to \\ string.
+ */
+static int tomoyo_get_absolute_path(struct dentry *dentry,
+struct vfsmount *vfsmnt,
+char *buffer,
+int buflen)
+{
+ char *start = buffer;
+ char *end = buffer + buflen;
+ int is_dir = (dentry->d_inode && S_ISDIR(dentry->d_inode->i_mode));
+
+ if (buflen < 256) goto out;
+
+ *--end = '\0';
+ buflen--;
+
+ for (;;) {
+ struct dentry *parent;
+
+ if (dentry == vfsmnt->mnt_root || IS_ROOT(dentry)) {
+ /* Global root? */
+ spin_lock(_lock);
+ if (vfsmnt->mnt_parent == vfsmnt) {
+ spin_unlock(_lock);
+ break;
+ }
+ dentry = vfsmnt->mnt_mountpoint;
+ vfsmnt = vfsmnt->mnt_parent;
+ spin_unlock(_lock);
+ continue;
+ }
+ if (is_dir) {
+ is_dir = 0;
+ *--end = '/';
+ buflen--;
+ }
+ parent =
[TOMOYO 5/9] Memory and pathname management functions.
We limit the maximum length of any string data (such as domainname and
pathnames)
to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page.
Userland programs can obtain the amount of RAM currently used by TOMOYO from
/proc interface.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/include/realpath.h | 46 +
security/tomoyo/realpath.c | 445
+
2 files changed, 491 insertions(+)
diff -ubBpErN linux-2.6.21.5/security/tomoyo/include/realpath.h
linux-2.6.21.5-tomoyo/security/tomoyo/include/realpath.h
--- linux-2.6.21.5/security/tomoyo/include/realpath.h 1970-01-01
09:00:00.0 +0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/include/realpath.h2007-06-05
00:00:00.0 +0900
@@ -0,0 +1,46 @@
+/*
+ * security/tomoyo/include/realpath.h
+ *
+ * Get the canonicalized absolute pathnames. The basis for TOMOYO.
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ *
+ */
+
+#ifndef _TOMOYO_REALPATH_H
+#define _TOMOYO_REALPATH_H
+
+struct path_info;
+
+/* Returns realpath(3) of the given pathname but ignores chroot'ed root. */
+int tomoyo_realpath_from_dentry2(struct dentry *dentry,
+ struct vfsmount *mnt,
+ char *newname,
+ int newname_len);
+
+/* Returns realpath(3) of the given pathname but ignores chroot'ed root. */
+/* These functions use tomoyo_alloc(), so caller must tomoyo_free() */
+/* if these functions didn't return NULL. */
+char *tomoyo_realpath(const char *pathname);
+char *tomoyo_realpath_nofollow(const char *pathname);
+char *tomoyo_realpath_from_dentry(struct dentry *dentry, struct vfsmount *mnt);
+
+/* Allocate memory for structures. */
+/* The RAM is chunked, so NEVER try to kfree() the returned pointer. */
+void *tomoyo_alloc_element(const unsigned int size);
+
+/* Get used RAM size for tomoyo_alloc_elements(). */
+unsigned int tomoyo_get_memory_used_for_elements(void);
+
+/* Keep the given name on the RAM. */
+/* The RAM is shared, so NEVER try to modify or kfree() the returned name. */
+const struct path_info *tomoyo_save_name(const char *name);
+
+/* Get used RAM size for tomoyo_save_name(). */
+unsigned int tomoyo_get_memory_used_for_save_name(void);
+
+unsigned int tomoyo_get_memory_used_for_dynamic(void);
+
+#endif
diff -ubBpErN linux-2.6.21.5/security/tomoyo/realpath.c
linux-2.6.21.5-tomoyo/security/tomoyo/realpath.c
--- linux-2.6.21.5/security/tomoyo/realpath.c 1970-01-01 09:00:00.0
+0900
+++ linux-2.6.21.5-tomoyo/security/tomoyo/realpath.c2007-06-14
15:06:37.0 +0900
@@ -0,0 +1,445 @@
+/*
+ * security/tomoyo/realpath.c
+ *
+ * Get the canonicalized absolute pathnames.
+ * The basis for TOMOYO Linux.
+ *
+ * Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 2.0 2007/06/05
+ */
+
+#include linux/string.h
+#include linux/mm.h
+#include linux/utime.h
+#include linux/file.h
+#include linux/smp_lock.h
+#include linux/module.h
+#include linux/slab.h
+#include asm/uaccess.h
+#include asm/atomic.h
+#include linux/namei.h
+#include linux/mount.h
+#include linux/proc_fs.h
+#include realpath.h
+#include tomoyo.h
+
+extern int sbin_init_started;
+
+/* realpath handler */
+
+/*
+ * tomoyo_get_absolute_path - return the path of a dentry but ignores
chroot'ed root.
+ * @dentry: dentry to report
+ * @vfsmnt: vfsmnt to which the dentry belongs
+ * @buffer: buffer to return value in
+ * @buflen: buffer length
+ *
+ * Caller holds the dcache_lock.
+ * Based on __d_path() in fs/dcache.c
+ *
+ * If dentry is a directory, trailing '/' is appended.
+ * Characters other than ' ' c 127 are converted to \ooo style octal
string.
+ * Character \ is converted to \\ string.
+ */
+static int tomoyo_get_absolute_path(struct dentry *dentry,
+struct vfsmount *vfsmnt,
+char *buffer,
+int buflen)
+{
+ char *start = buffer;
+ char *end = buffer + buflen;
+ int is_dir = (dentry-d_inode S_ISDIR(dentry-d_inode-i_mode));
+
+ if (buflen 256) goto out;
+
+ *--end = '\0';
+ buflen--;
+
+ for (;;) {
+ struct dentry *parent;
+
+ if (dentry == vfsmnt-mnt_root || IS_ROOT(dentry)) {
+ /* Global root? */
+ spin_lock(vfsmount_lock);
+ if (vfsmnt-mnt_parent == vfsmnt) {
+ spin_unlock(vfsmount_lock);
+ break;
+ }
+ dentry = vfsmnt-mnt_mountpoint;
+ vfsmnt = vfsmnt-mnt_parent;
+ spin_unlock(vfsmount_lock);
+ continue;
+ }
+ if (is_dir) {
+
Re: [TOMOYO 5/9] Memory and pathname management functions.
On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: We limit the maximum length of any string data (such as domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page. Userland programs can obtain the amount of RAM currently used by TOMOYO from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Christoph Hellwig wrote: On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: We limit the maximum length of any string data (such as domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page. Userland programs can obtain the amount of RAM currently used by TOMOYO from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. TOMOYO Linux is a pathname-based MAC, that is true. But what that patch aimed for was sharing the idea of having Linux kernel to keep process invocation history information for each process. In that sense, TOMOYO Linux is just a sample implementation. Please take a look at the following message: http://lkml.org/lkml/2007/6/13/58 Best regards, Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
