hannes:

package/base/linux/linux26/80-ext23-suiddir.patch

@@ -63,9 +63,45 @@
  S: Foehrengasse 16
  S: A-2333 Leopoldsdorf b. Wien
  S: Austria
---- ./fs/Kconfig.orig	2003-06-07 18:13:43.000000000 +0200
-+++ ./fs/Kconfig	2003-06-07 18:16:50.000000000 +0200
-@@ -155,6 +155,35 @@
+--- ./fs/Kconfig.old	2004-09-13 10:51:35.040756792 +0200
++++ ./fs/Kconfig	2004-09-13 10:48:00.735336168 +0200
+@@ -50,6 +50,35 @@
+ 	  If you are not using a security module that requires using
+ 	  extended attributes for file security labels, say N.
+ 
++config EXT2_FS_SUIDDIR
++	bool "Ext2fs SUID on Directory Extension"
++	depends on EXT2_FS
++	---help---
++	   As you might know, the SGID flag has a special function on
++	   directories: files within that directories will be owned by
++	   the same group that also owns the directory - which is useful
++	   for creating directories which are shared between the members
++	   of a group.
++
++	   But that only makes sense if the umask is set to give full
++	   permissions to the group (e.g. 007 or 002). Noone would do that
++	   if there is a system-wide 'users' group - so some distributions
++	   add an extra group for every user which lets the /etc/group
++	   file grow very fast and makes the admins life harder ...
++
++	   Activating this feture adds a function to the SUID flag on
++	   directories, which usually has no function at all:
++
++	   If the SUID flag is set for a diectory, all new files in that
++	   directory will get the same rights in the group-field as they
++	   have in their user-field.  So, if one sets both - SUID and SGID
++	   - on a directory, it will also work with a umask like 022 or
++	   077 and there is no more need for an extra group for every user.
++
++	   Also, the SUID flag will be set to all subdirectories of a
++	   SUID directory (as it is already now with the SGID flag on
++	   directories).
++
+ config EXT3_FS
+ 	tristate "Ext3 journalling file system support"
+ 	help
+@@ -118,6 +147,35 @@
  	  If you are not using a security module that requires using
  	  extended attributes for file security labels, say N.
  
@@ -101,39 +137,12 @@
  config JBD
  # CONFIG_JBD could be its own option (even modular), but until there are
  # other users than ext3, we will simply make it be the same as CONFIG_EXT3_FS
-@@ -1183,6 +1212,35 @@
- 
+@@ -1289,8 +1347,6 @@
+ 	  It's currently broken, so for now:
+ 	  answer N.
  
- 
-+config EXT2_FS_SUIDDIR
-+	bool "Ext2fs SUID on Directory Extension"
-+	depends on EXT2_FS
-+	---help---
-+	   As you might know, the SGID flag has a special function on
-+	   directories: files within that directories will be owned by
-+	   the same group that also owns the directory - which is useful
-+	   for creating directories which are shared between the members
-+	   of a group.
-+
-+	   But that only makes sense if the umask is set to give full
-+	   permissions to the group (e.g. 007 or 002). Noone would do that
-+	   if there is a system-wide 'users' group - so some distributions
-+	   add an extra group for every user which lets the /etc/group
-+	   file grow very fast and makes the admins life harder ...
-+
-+	   Activating this feture adds a function to the SUID flag on
-+	   directories, which usually has no function at all:
-+
-+	   If the SUID flag is set for a diectory, all new files in that
-+	   directory will get the same rights in the group-field as they
-+	   have in their user-field.  So, if one sets both - SUID and SGID
-+	   - on a directory, it will also work with a umask like 022 or
-+	   077 and there is no more need for an extra group for every user.
-+
-+	   Also, the SUID flag will be set to all subdirectories of a
-+	   SUID directory (as it is already now with the SGID flag on
-+	   directories).
-+
+-
+-
  config SYSV_FS
  	tristate "System V/Xenix/V7/Coherent file system support"
  	help