Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1342047 > unrolled thread

[PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup.

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup. Ignacy Gawędzki   <ignacy.gawedzki@green-communications.fr> - 2016-02-24 15:00 +0100
    Re: [PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup. Vivek Goyal <vgoyal@redhat.com> - 2016-02-26 20:50 +0100
      Re: [PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup. Nazarov Sergey <s-nazarov@yandex.ru> - 2016-02-27 12:00 +0100
        Re: [PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup. Vivek Goyal <vgoyal@redhat.com> - 2016-02-29 17:40 +0100
      Re: [PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup. Ignacy Gawędzki   <ignacy.gawedzki@green-communications.fr> - 2016-02-28 12:20 +0100
        Re: [PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup. Vivek Goyal <vgoyal@redhat.com> - 2016-02-29 17:30 +0100
          Re: [PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup. Ignacy Gawędzki   <ignacy.gawedzki@green-communications.fr> - 2016-02-29 18:00 +0100

#1342047 — [PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup.

Add alternate lookup_one_len_check function to fs/namei.c which does
what lookup_one_len did until now with a boolean argument telling
whether to check that the base directory is traversable.  Modify
original lookup_one_len function to call the former with true as the
last argument.

In function ovl_lookup_real, file fs/overlayfs/super.c, call
lookup_one_len_check with false as the last argument, so that failure
to traverse the base directory does not return -EACCES.  This should
make lookup resolution work properly in the following setup

  drwxr-xr-x lower/
  drwx------ lower/foo/
  drw-r--r-- lower/boo/bar
  drwxr-xr-x upper/
  drwxr-xr-x upper/foo/

when any user not being the owner of lower/foo is trying to access
foo/bar in the mounted overlay.

Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
---
 fs/namei.c            | 29 +++++++++++++++++++++++++----
 fs/overlayfs/super.c  |  2 +-
 include/linux/namei.h |  1 +
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index f624d13..f9486da 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2278,6 +2278,25 @@ EXPORT_SYMBOL(vfs_path_lookup);
  */
 struct dentry *lookup_one_len(const char *name, struct dentry *base, int len)
 {
+	return lookup_one_len_check(name, base, len, true);
+}
+EXPORT_SYMBOL(lookup_one_len);
+
+/**
+ * lookup_one_len_check - filesystem helper to lookup single pathname component
+ * @name:	pathname component to lookup
+ * @base:	base directory to lookup from
+ * @len:	maximum length @len should be interpreted to
+ * @check:	whether to check that @base is itself traversable.
+ *
+ * Note that this routine is purely a helper for filesystem usage and should
+ * not be called by generic code.
+ *
+ * The caller must hold base->i_mutex.
+ */
+struct dentry *lookup_one_len_check(const char *name, struct dentry *base,
+				    int len, bool check_base)
+{
 	struct qstr this;
 	unsigned int c;
 	int err;
@@ -2310,13 +2329,15 @@ struct dentry *lookup_one_len(const char *name, struct dentry *base, int len)
 			return ERR_PTR(err);
 	}
 
-	err = inode_permission(base->d_inode, MAY_EXEC);
-	if (err)
-		return ERR_PTR(err);
+	if (check_base) {
+		err = inode_permission(base->d_inode, MAY_EXEC);
+		if (err)
+			return ERR_PTR(err);
+	}
 
 	return __lookup_hash(&this, base, 0);
 }
-EXPORT_SYMBOL(lookup_one_len);
+EXPORT_SYMBOL(lookup_one_len_check);
 
 /**
  * lookup_one_len_unlocked - filesystem helper to lookup single pathname component
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 8d826bd..965c5dd 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -376,7 +376,7 @@ static inline struct dentry *ovl_lookup_real(struct dentry *dir,
 	struct dentry *dentry;
 
 	inode_lock(dir->d_inode);
-	dentry = lookup_one_len(name->name, dir, name->len);
+	dentry = lookup_one_len_check(name->name, dir, name->len, false);
 	inode_unlock(dir->d_inode);
 
 	if (IS_ERR(dentry)) {
diff --git a/include/linux/namei.h b/include/linux/namei.h
index d0f25d8..0af6775 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -77,6 +77,7 @@ extern struct dentry *kern_path_locked(const char *, struct path *);
 extern int kern_path_mountpoint(int, const char *, struct path *, unsigned int);
 
 extern struct dentry *lookup_one_len(const char *, struct dentry *, int);
+extern struct dentry *lookup_one_len_check(const char *, struct dentry *, int, bool);
 extern struct dentry *lookup_one_len_unlocked(const char *, struct dentry *, int);
 
 extern int follow_down_one(struct path *);
-- 
2.5.0

[toc] | [next] | [standalone]

#1344625

CCing linux-fsdevel as it is a wider issue.


On Wed, Feb 24, 2016 at 02:55:52PM +0100, Ignacy Gawędzki wrote:
> Add alternate lookup_one_len_check function to fs/namei.c which does
> what lookup_one_len did until now with a boolean argument telling
> whether to check that the base directory is traversable.  Modify
> original lookup_one_len function to call the former with true as the
> last argument.
> 
> In function ovl_lookup_real, file fs/overlayfs/super.c, call
> lookup_one_len_check with false as the last argument, so that failure
> to traverse the base directory does not return -EACCES.  This should
> make lookup resolution work properly in the following setup
> 
>   drwxr-xr-x lower/
>   drwx------ lower/foo/
>   drw-r--r-- lower/boo/bar
>   drwxr-xr-x upper/
>   drwxr-xr-x upper/foo/
> 
> when any user not being the owner of lower/foo is trying to access
> foo/bar in the mounted overlay.

So what's the problem we are trying to solve. Why should we able to
override the DAC checks of lower layer if same directory in upper
is searchable for user but it is not searchable in lower layer. 

Thanks
Vivek

> 
> Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
> ---
>  fs/namei.c            | 29 +++++++++++++++++++++++++----
>  fs/overlayfs/super.c  |  2 +-
>  include/linux/namei.h |  1 +
>  3 files changed, 27 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index f624d13..f9486da 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2278,6 +2278,25 @@ EXPORT_SYMBOL(vfs_path_lookup);
>   */
>  struct dentry *lookup_one_len(const char *name, struct dentry *base, int len)
>  {
> +	return lookup_one_len_check(name, base, len, true);
> +}
> +EXPORT_SYMBOL(lookup_one_len);
> +
> +/**
> + * lookup_one_len_check - filesystem helper to lookup single pathname component
> + * @name:	pathname component to lookup
> + * @base:	base directory to lookup from
> + * @len:	maximum length @len should be interpreted to
> + * @check:	whether to check that @base is itself traversable.
> + *
> + * Note that this routine is purely a helper for filesystem usage and should
> + * not be called by generic code.
> + *
> + * The caller must hold base->i_mutex.
> + */
> +struct dentry *lookup_one_len_check(const char *name, struct dentry *base,
> +				    int len, bool check_base)
> +{
>  	struct qstr this;
>  	unsigned int c;
>  	int err;
> @@ -2310,13 +2329,15 @@ struct dentry *lookup_one_len(const char *name, struct dentry *base, int len)
>  			return ERR_PTR(err);
>  	}
>  
> -	err = inode_permission(base->d_inode, MAY_EXEC);
> -	if (err)
> -		return ERR_PTR(err);
> +	if (check_base) {
> +		err = inode_permission(base->d_inode, MAY_EXEC);
> +		if (err)
> +			return ERR_PTR(err);
> +	}
>  
>  	return __lookup_hash(&this, base, 0);
>  }
> -EXPORT_SYMBOL(lookup_one_len);
> +EXPORT_SYMBOL(lookup_one_len_check);
>  
>  /**
>   * lookup_one_len_unlocked - filesystem helper to lookup single pathname component
> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> index 8d826bd..965c5dd 100644
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -376,7 +376,7 @@ static inline struct dentry *ovl_lookup_real(struct dentry *dir,
>  	struct dentry *dentry;
>  
>  	inode_lock(dir->d_inode);
> -	dentry = lookup_one_len(name->name, dir, name->len);
> +	dentry = lookup_one_len_check(name->name, dir, name->len, false);
>  	inode_unlock(dir->d_inode);
>  
>  	if (IS_ERR(dentry)) {
> diff --git a/include/linux/namei.h b/include/linux/namei.h
> index d0f25d8..0af6775 100644
> --- a/include/linux/namei.h
> +++ b/include/linux/namei.h
> @@ -77,6 +77,7 @@ extern struct dentry *kern_path_locked(const char *, struct path *);
>  extern int kern_path_mountpoint(int, const char *, struct path *, unsigned int);
>  
>  extern struct dentry *lookup_one_len(const char *, struct dentry *, int);
> +extern struct dentry *lookup_one_len_check(const char *, struct dentry *, int, bool);
>  extern struct dentry *lookup_one_len_unlocked(const char *, struct dentry *, int);
>  
>  extern int follow_down_one(struct path *);
> -- 
> 2.5.0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1344985

26.02.2016, 22:41, "Vivek Goyal" <vgoyal@redhat.com>:
>
> So what's the problem we are trying to solve. Why should we able to
> override the DAC checks of lower layer if same directory in upper
> is searchable for user but it is not searchable in lower layer.
>

If I right, this is a one of the main feature of overlayfs - upper layer has priority over lower ones.
Override AC checks necessary for lookup operation only. Lower layer files access AC checks
remain, so this should not be a security problem.
Sergey.

[toc] | [prev] | [next] | [standalone]

#1345979

On Sat, Feb 27, 2016 at 01:40:02PM +0300, Nazarov Sergey wrote:
> 26.02.2016, 22:41, "Vivek Goyal" <vgoyal@redhat.com>:
> >
> > So what's the problem we are trying to solve. Why should we able to
> > override the DAC checks of lower layer if same directory in upper
> > is searchable for user but it is not searchable in lower layer.
> >
> 
> If I right, this is a one of the main feature of overlayfs - upper layer has priority over lower ones.
> Override AC checks necessary for lookup operation only. Lower layer files access AC checks
> remain, so this should not be a security problem.

So a directory which is not searchable by user in lower layer suddenly
becomes searchable once union is created. In fact there are two cases.
If upper layer directory does exist, then it is not searchable. If 
upper layer direcotry does exist with user having search permissions, then
lower layer directory should become searchable? May be, I don't know.

Thanks
Vivek

[toc] | [prev] | [next] | [standalone]

#1345218

On Fri, Feb 26, 2016 at 02:41:43PM -0500, thus spake Vivek Goyal:
> CCing linux-fsdevel as it is a wider issue.
> 
> 
> On Wed, Feb 24, 2016 at 02:55:52PM +0100, Ignacy Gawędzki wrote:
> > Add alternate lookup_one_len_check function to fs/namei.c which does
> > what lookup_one_len did until now with a boolean argument telling
> > whether to check that the base directory is traversable.  Modify
> > original lookup_one_len function to call the former with true as the
> > last argument.
> > 
> > In function ovl_lookup_real, file fs/overlayfs/super.c, call
> > lookup_one_len_check with false as the last argument, so that failure
> > to traverse the base directory does not return -EACCES.  This should
> > make lookup resolution work properly in the following setup
> > 
> >   drwxr-xr-x lower/
> >   drwx------ lower/foo/
> >   drw-r--r-- lower/boo/bar
> >   drwxr-xr-x upper/
> >   drwxr-xr-x upper/foo/
> > 
> > when any user not being the owner of lower/foo is trying to access
> > foo/bar in the mounted overlay.
> 
> So what's the problem we are trying to solve. Why should we able to
> override the DAC checks of lower layer if same directory in upper
> is searchable for user but it is not searchable in lower layer. 

My point is that an overlay filesystem should have consistent
semantics.  The current state of affairs fails in this regard on two
points.  First, suppose you have the same lower as above, but upper is
empty.  Then initially, foo/ has permissions 700 and shouldn't be
traversable by anyone but user root and the owner of foo/.  But if user
root or the owner changes foo's permissions to 755, a foo directory is
created in the upper layer and we arrive at the exact same
configuration as above.  In this case, I don't think anyone would
expect other users be denied traversal of foo to access bar.  Second,
the state of the cache shouldn't have any influence on the way access
rights are enforced.  In the present case, traversal of foo is granted
to other users depending on whether the owner or root already accessed
bar.

Besides, according to Documentation/fs/overlay.txt:

  Only the lists of names from directories are merged.  Other content
  such as metadata and extended attributes are reported for the upper
  directory only.  These attributes of the lower directory are hidden.

which implies that lower's permissions of foo should be ignored if foo
exists in upper as well.

Cheers,

Ignacy

-- 
Ignacy Gawędzki
R&D Engineer
Green Communications

[toc] | [prev] | [next] | [standalone]

#1345967

On Sun, Feb 28, 2016 at 12:09:42PM +0100, Ignacy Gawędzki wrote:
> On Fri, Feb 26, 2016 at 02:41:43PM -0500, thus spake Vivek Goyal:
> > CCing linux-fsdevel as it is a wider issue.
> > 
> > 
> > On Wed, Feb 24, 2016 at 02:55:52PM +0100, Ignacy Gawędzki wrote:
> > > Add alternate lookup_one_len_check function to fs/namei.c which does
> > > what lookup_one_len did until now with a boolean argument telling
> > > whether to check that the base directory is traversable.  Modify
> > > original lookup_one_len function to call the former with true as the
> > > last argument.
> > > 
> > > In function ovl_lookup_real, file fs/overlayfs/super.c, call
> > > lookup_one_len_check with false as the last argument, so that failure
> > > to traverse the base directory does not return -EACCES.  This should
> > > make lookup resolution work properly in the following setup
> > > 
> > >   drwxr-xr-x lower/
> > >   drwx------ lower/foo/
> > >   drw-r--r-- lower/boo/bar
> > >   drwxr-xr-x upper/
> > >   drwxr-xr-x upper/foo/
> > > 
> > > when any user not being the owner of lower/foo is trying to access
> > > foo/bar in the mounted overlay.
> > 
> > So what's the problem we are trying to solve. Why should we able to
> > override the DAC checks of lower layer if same directory in upper
> > is searchable for user but it is not searchable in lower layer. 
> 
> My point is that an overlay filesystem should have consistent
> semantics.  The current state of affairs fails in this regard on two
> points.  First, suppose you have the same lower as above, but upper is
> empty.  Then initially, foo/ has permissions 700 and shouldn't be
> traversable by anyone but user root and the owner of foo/.  But if user
> root or the owner changes foo's permissions to 755, a foo directory is
> created in the upper layer and we arrive at the exact same
> configuration as above.  In this case, I don't think anyone would
> expect other users be denied traversal of foo to access bar.

I agree that semantics should be more consistent. I don't know that
if upper layer should override lower layer checks or not.

One could also argue that if root did chown, then changes effectively
happened in upper layer and anything in upper layer should become
visible to unpriviliged user but not the one in lower layer. 

I just don't know. I guess those who have more background on this
could pitch in and clarify that was is supposed to be the design
intention.


> Second,
> the state of the cache shouldn't have any influence on the way access
> rights are enforced.  In the present case, traversal of foo is granted
> to other users depending on whether the owner or root already accessed
> bar.

If we decide not to override checks from lower layer, then this is
an isue at caching level and requires fixing at that level.

> 
> Besides, according to Documentation/fs/overlay.txt:
> 
>   Only the lists of names from directories are merged.  Other content
>   such as metadata and extended attributes are reported for the upper
>   directory only.  These attributes of the lower directory are hidden.
> 
> which implies that lower's permissions of foo should be ignored if foo
> exists in upper as well.

Right, but it does not say anything about what happens to DAC checks
at lower layer. IOW, it does not say that if lower directory owner
is different then whether files from that directory will become searchable
or not.

Thanks
Vivek

[toc] | [prev] | [next] | [standalone]

#1345994

On Mon, Feb 29, 2016 at 11:25:46AM -0500, thus spake Vivek Goyal:
> I agree that semantics should be more consistent. I don't know that
> if upper layer should override lower layer checks or not.
> 
> One could also argue that if root did chown, then changes effectively
> happened in upper layer and anything in upper layer should become
> visible to unpriviliged user but not the one in lower layer. 
> 
> I just don't know. I guess those who have more background on this
> could pitch in and clarify that was is supposed to be the design
> intention.
> 
> [...]
> 
> Right, but it does not say anything about what happens to DAC checks
> at lower layer. IOW, it does not say that if lower directory owner
> is different then whether files from that directory will become searchable
> or not.

I suppose that looking at these questions from the perspective of the
primary application of OverlayFS, i.e. embedded systems with lower
being some read-only SquashFS and upper being read-write, may give
some good intuition on how this should work.  If the root user changes
access rights to some directories, then it is natural that permissions in
upper are less restrictive than permissions in lower and this in no
way breaks any security.  If you're thinking about what happens if
some overlay is mounted where the more permissive directory in upper
shadows a less permissive one in lower, then well, the only user able
to mount such an overlay, i.e. root, should know what she's doing.

Anyway, DAC checks should be consistent from the standpoint of
userland, first and foremost.

-- 
Ignacy Gawędzki
R&D Engineer
Green Communications

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web