headers
ye janboe | 19 Jul 12:01
Picon

jffs2 statfs issue

jffs2 can not return correct free space amount.
I checked jffs2_statfs, there is problem.

	avail = c->dirty_size + c->free_size;
	if (avail > c->sector_size * c->resv_blocks_write)
		avail -= c->sector_size * c->resv_blocks_write;
	else
		avail = 0;

But in jffs2_reserve_space, c->dirty_size will compare to
c->nospc_dirty_size. If dirty < c->nospc_dirty_size, it will return
nospace error.

So I change above code to
	dirty = c->dirty_size + c->erasing_size - c->nr_erasing_blocks *
c->sector_size + c->unchecked_size;
	if (dirty > c->nospc_dirty_size)
		avail = c->dirty_size + c->free_size - c->nospc_dirty_size;
	else
		avail = c->free_size;

Do this make sense?

Thanks a lot!

Janboe
Permalink | Reply | 0 comments |
headers
Adrian Bunk | 29 Jul 17:02
Picon
Favicon

[RFC: 2.6 patch] make the *FS_SECURITY options no longer user visible

Please correct me if any of the following assumptions is wrong:
- SELinux is currently the only user of filesystem security labels
  shipped with the Linux kernel
- if a user has SELinux enabled he wants his filesystems to support
  security labels

Based on these assumption, it doesn't make sense to have the
*FS_SECURITY user visible since we can perfectly determine automatically 
when turning them on makes sense.

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>

---

 fs/Kconfig     |   82 +++++++++++++------------------------------------
 fs/xfs/Kconfig |   13 +------
 2 files changed, 25 insertions(+), 70 deletions(-)

--- linux-2.6.23-rc1-mm1/fs/Kconfig.old	2007-07-28 23:12:19.000000000 +0200
+++ linux-2.6.23-rc1-mm1/fs/Kconfig	2007-07-28 23:17:33.000000000 +0200
@@ -40,16 +40,10 @@ config EXT2_FS_POSIX_ACL
 	  If you don't know what Access Control Lists are, say N

 config EXT2_FS_SECURITY
-	bool "Ext2 Security Labels"
-	depends on EXT2_FS_XATTR
-	help
-	  Security labels support alternative access control models
-	  implemented by security modules like SELinux.  This option
-	  enables an extended attribute handler for file security
(Continue reading)

Permalink | Reply | 2 comments |
headers
Adrian Bunk | 29 Jul 17:02
Picon
Favicon

[2.6 patch] remove fs/jffs2/ioctl.c

fs/jffs2/ioctl.c is already for so long in the "might be used later" 
state that I doubt it will ever be actually used...

And if it will ever be used, reverting this patch will be trivial.

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>

---

 fs/jffs2/Makefile   |    2 +-
 fs/jffs2/dir.c      |    1 -
 fs/jffs2/file.c     |    1 -
 fs/jffs2/ioctl.c    |   21 ---------------------
 fs/jffs2/os-linux.h |    3 ---
 5 files changed, 1 insertion(+), 27 deletions(-)

--- linux-2.6.14-rc5-mm1-full/fs/jffs2/os-linux.h.old	2005-11-01 20:28:24.000000000 +0100
+++ linux-2.6.14-rc5-mm1-full/fs/jffs2/os-linux.h	2005-11-01 20:28:31.000000000 +0100
@@ -147,9 +147,6 @@
 int jffs2_fsync(struct file *, struct dentry *, int);
 int jffs2_do_readpage_unlock (struct inode *inode, struct page *pg);

-/* ioctl.c */
-int jffs2_ioctl(struct inode *, struct file *, unsigned int, unsigned long);
-
 /* symlink.c */
 extern struct inode_operations jffs2_symlink_inode_operations;

--- linux-2.6.14-rc5-mm1-full/fs/jffs2/dir.c.old	2005-11-01 20:28:39.000000000 +0100
+++ linux-2.6.14-rc5-mm1-full/fs/jffs2/dir.c	2005-11-01 20:28:43.000000000 +0100
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Chinner | 30 Jul 01:29
Picon
Favicon

Re: [xfs-masters] [RFC: 2.6 patch] make the *FS_SECURITY options no longer user visible

On Sun, Jul 29, 2007 at 05:02:09PM +0200, Adrian Bunk wrote:
> Please correct me if any of the following assumptions is wrong:
> - SELinux is currently the only user of filesystem security labels
>   shipped with the Linux kernel
> - if a user has SELinux enabled he wants his filesystems to support
>   security labels
> 
> Based on these assumption, it doesn't make sense to have the
> *FS_SECURITY user visible since we can perfectly determine automatically 
> when turning them on makes sense.

Hmmm. The code in XFS is not dependent on selinux, but this change
would mean that testing the security xattr namespace would require a
selinux enabled kernel.

I agree that the default for these should be "y" and selected if
selinux is enabled, but forcing us to use selinux enabled kernels
(on distro's that may not support selinux) just to test the
security xattr namespace is a bit of a pain.

Cheers,

Dave.
--

-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Smalley | 30 Jul 14:27
Picon

Re: [xfs-masters] [RFC: 2.6 patch] make the *FS_SECURITY options no longer user visible

On Mon, 2007-07-30 at 09:29 +1000, David Chinner wrote:
> On Sun, Jul 29, 2007 at 05:02:09PM +0200, Adrian Bunk wrote:
> > Please correct me if any of the following assumptions is wrong:
> > - SELinux is currently the only user of filesystem security labels
> >   shipped with the Linux kernel
> > - if a user has SELinux enabled he wants his filesystems to support
> >   security labels
> > 
> > Based on these assumption, it doesn't make sense to have the
> > *FS_SECURITY user visible since we can perfectly determine automatically 
> > when turning them on makes sense.
> 
> Hmmm. The code in XFS is not dependent on selinux, but this change
> would mean that testing the security xattr namespace would require a
> selinux enabled kernel.
> 
> I agree that the default for these should be "y" and selected if
> selinux is enabled, but forcing us to use selinux enabled kernels
> (on distro's that may not support selinux) just to test the
> security xattr namespace is a bit of a pain.

You can enable SECURITY_SELINUX in the kernel config but still have it
boot disabled by default via SECURITY_SELINUX_BOOTPARAM_VALUE=0.

--

-- 
Stephen Smalley
National Security Agency

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Serge E. Hallyn | 30 Jul 15:12
Picon
Favicon
Gravatar

Re: [RFC: 2.6 patch] make the *FS_SECURITY options no longer user visible

Quoting Adrian Bunk (bunk <at> stusta.de):
> Please correct me if any of the following assumptions is wrong:
> - SELinux is currently the only user of filesystem security labels
>   shipped with the Linux kernel
> - if a user has SELinux enabled he wants his filesystems to support
>   security labels
> 
> Based on these assumption, it doesn't make sense to have the
> *FS_SECURITY user visible since we can perfectly determine automatically 
> when turning them on makes sense.

I'm not very knowledgeable on the niftier kconfig features.  Is there a
way to introduce some intermediate SECURITY_XATTR variable, which
SECURITY_SELINUX could select, and which *_FS_SECURITY could depend on?

That way patches for file capabilities (in -mm) and smack (being
discussed on linux-security-module) won't have to explicitly add
themselves to every one of those 'depends on' lines.

thanks,
-serge

> Signed-off-by: Adrian Bunk <bunk <at> stusta.de>
> 
> ---
> 
>  fs/Kconfig     |   82 +++++++++++++------------------------------------
>  fs/xfs/Kconfig |   13 +------
>  2 files changed, 25 insertions(+), 70 deletions(-)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Layton | 25 Jul 18:47
Picon
Favicon

[PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions

( Please consider trimming the Cc list if discussing some aspect of this that doesn't concern everyone )

When an unprivileged process attempts to modify a file that has the
setuid or setgid bits set, the VFS will attempt to clear these bits. The
VFS will set the ATTR_KILL_SUID or ATTR_KILL_SGID bits in the ia_valid
mask, and then call notify_change to clear these bits and set the mode
accordingly.

With a networked filesystem (NFS in particular but most likely others),
the client machine may not have credentials that allow for the clearing
of these bits. In some situations, this can lead to file corruption, or
to an operation failing outright because the setattr fails.

In this situation, we'd like to just leave the handling of this to
the server and ignore these bits. The problem is that by the time
nfs_setattr is called, the VFS has already reinterpreted the ATTR_KILL_*
bits into a mode change. We can't fix this in the filesystems where
this is a problem, as doing so would leave us having to second-guess
what the VFS wants us to do. So we need to change it so that filesystems
have more flexibility in how to interpret the ATTR_KILL_* bits.

The first patch in the following patchset moves this logic into a helper
function, and then only calls this helper function for inodes that do
not have a setattr operation defined. The subsequent patches fix up
individual filesystem setattr functions to call this helper function.

The upshot of this is that with this change, filesystems that define
a setattr inode operation are now responsible for handling the ATTR_KILL
bits as well. They can trivially do so by calling the helper, but they
must do so.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Layton | 25 Jul 18:47
Picon
Favicon

[PATCH 01/25] VFS: move attr_kill logic from notify_change into helper function

Separate the handling of the local ia_valid bitmask from the one in
attr->ia_valid. This allows us to hand off the actual handling of the
ATTR_KILL_* flags to the .setattr i_op when one is defined.

notify_change still needs to process those flags for the local ia_valid
variable, since it uses that to decide whether to return early, and to pass
a (hopefully) appropriate bitmask to fsnotify_change.

Signed-off-by: Jeff Layton <jlayton <at> redhat.com>
---
 fs/attr.c          |   54 +++++++++++++++++++++++++++++++++------------------
 include/linux/fs.h |    1 +
 2 files changed, 36 insertions(+), 19 deletions(-)

diff --git a/fs/attr.c b/fs/attr.c
index f8dfc22..47015e0 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -100,15 +100,39 @@ int inode_setattr(struct inode * inode, struct iattr * attr)
 }
 EXPORT_SYMBOL(inode_setattr);

+void attr_kill_to_mode(struct inode *inode, struct iattr *attr)
+{
+	if (attr->ia_valid & ATTR_KILL_SUID) {
+		attr->ia_valid &= ~ATTR_KILL_SUID;
+		if (inode->i_mode & S_ISUID) {
+			if (!(attr->ia_valid & ATTR_MODE)) {
+				attr->ia_valid |= ATTR_MODE;
+				attr->ia_mode = inode->i_mode;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Layton | 24 Jul 19:00
Picon
Favicon

[PATCH 14/25] JFFS2: call attr_kill_to_mode from jffs2_do_setattr


Signed-off-by: Jeff Layton <jlayton <at> redhat.com>
---
 fs/jffs2/fs.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c
index 1d3b7a9..5218f04 100644
--- a/fs/jffs2/fs.c
+++ b/fs/jffs2/fs.c
@@ -37,6 +37,7 @@ static int jffs2_do_setattr (struct inode *inode, struct iattr *iattr)
 	uint32_t alloclen;
 	int ret;
 	D1(printk(KERN_DEBUG "jffs2_setattr(): ino #%lu\n", inode->i_ino));
+	attr_kill_to_mode(inode, iattr);
 	ret = inode_change_ok(inode, iattr);
 	if (ret)
 		return ret;
--

-- 
1.5.2.2

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane