All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruen@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, Gerard Neil <xyzzy@devferret.org>,
	Dave Kleikamp <shaggy@austin.ibm.com>,
	Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH] Fix user.* xattr permission check for sticky dirs
Date: Thu, 2 Nov 2006 22:51:21 +0100	[thread overview]
Message-ID: <200611022251.21816.agruen@suse.de> (raw)
In-Reply-To: <20061102112741.e1bb88c9.akpm@osdl.org>

On Thursday 02 November 2006 20:27, Andrew Morton wrote:
> On Thu, 2 Nov 2006 17:24:02 +0100
>
> Andreas Gruenbacher <agruen@suse.de> wrote:
> > The user.* extended attributes are only allowed on regular files and
> > directories. Sticky directories further restrict write access to the
> > owner and privileged users. (See the attr(5) man page for an
> > explanation.)
> >
> > The original check in ext2/ext3 when user.* xattrs were merged was more
> > restrictive than intended, and when the xattr permission checks were
> > moved into the VFS, read access to user.* attributes on sticky directores
> > ended up being denied in addition.
>
> Am struggling to understand the impact of this.  I assume this problem was
> introduced on Jan 9 by e0ad7b073eb7317e5afe0385b02dcb1d52a1eedf "move xattr
> permission checks into the VFS"?

Commits e0ad7b073eb7317e5afe0385b02dcb1d52a1eedf and 
c37ef806a3e1c0bca65fd03b7590d56d19625da4 move the following check from 
ext3_xattr_user_set() to xattr_permission(), which is used in vfs_getxattr() 
as well as xfs_setxattr() and vfs_removexattr(), so this added the check to 
the xfs_getxattr() path by accident:

[]	if (!S_ISREG(inode->i_mode) &&
[]	    (!S_ISDIR(inode->i_mode) || inode->i_mode & S_ISVTX))
[]		return -EPERM;

The check itself completely forbids user.* xattrs for sticky directories 
already though, and this conflicts with the xattr(5) manual page as well as 
the xfs code. It looks as if the ckeck was more strict than intended since 
forever. The patch I have sent relaxes the unintended restriction.

> If so, the fix is applicable to 2.6.18, 2.6.19 and of course 2.6.20.

... and further back.

> But to which of those should it be applied?

I don't think we'll need backports; this doesn't address a security problem.

Thanks,
Andreas

  reply	other threads:[~2006-11-02 21:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-02 16:24 [PATCH] Fix user.* xattr permission check for sticky dirs Andreas Gruenbacher
2006-11-02 16:59 ` Jan Engelhardt
2006-11-02 17:14   ` Dave Kleikamp
2006-11-02 19:27 ` Andrew Morton
2006-11-02 21:51   ` Andreas Gruenbacher [this message]
2006-11-03  4:57     ` Timothy Shimmin
2006-11-03  8:38       ` Andreas Gruenbacher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200611022251.21816.agruen@suse.de \
    --to=agruen@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaggy@austin.ibm.com \
    --cc=torvalds@osdl.org \
    --cc=xyzzy@devferret.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.