All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olaf Dietsche <olaf--list.linux-kernel@olafdietsche.de>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: Serge Hallyn <serge.hallyn@canonical.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 3.8: access permission filesystem
Date: Wed, 19 Mar 2014 23:07:07 +0100	[thread overview]
Message-ID: <874n2tonas.fsf@olafdietsche.de> (raw)
In-Reply-To: 874n2t6get.fsf@xmission.com

ebiederm@xmission.com (Eric W. Biederman) writes:

> Olaf Dietsche <olaf--list.linux-kernel@olafdietsche.de> writes:
>
>> I am in the process of catching up with the last two years or so.
>> Right now, I am at the changes involving user namespaces.
>>
>> I have two possible implementations, both working equally well in a
>> shared environment. Since I am not familiar with namespaces in general
>> and user namespaces in particular, I would like you to look over the
>> patches and tell me, what you think.
>>
>> Are the patches good so far? Are there are any things I missed and must
>> consider? Maybe, I am completely off track? Anything else?
>>
>> I included both patches inline below. The patches are also available as
>> separate branches at github 
>>
>> https://github.com/olafdietsche/linux-accessfs/tree/tmp-user-ns-1
>> https://github.com/olafdietsche/linux-accessfs/tree/tmp-user-ns-2
>>
>> I am leaning toward the second patch. Although it is a little bit longer
>> than the first one, it involves no user id conversions.
>
> Using kuid's and kgid's throughout as your second patch does is best.
> Conversion is only needed on normal filesystems because they have a
> backing store and reside on disk.  As accessfs appears not to have
> backing store, storing things with kuid's and kgid's is the preferred
> method.
>
> Your first patch is buggy as it uses current_user_ns().  Something a
> filesystem in general should not care about.

I have seen similar uses in other filesystems like ext3, jfs or
debugfs. What would be the correct way to use make_kuid() or make_gid()?

> I don't see anything wrong with your second patch.

Thanks a lot for this fast response and your guidance. So, I will dump
the first and continue with the second patch.

> From what little I understand of accessfs, I expect you will want to
> play with and come up to speed on namespaces, as namespaces change
> the universe of objects you will be dealing with, in some subtle
> but interesting ways.  At least assuming anyone in who uses accessfs
> is going to be using more than a single container.
>
> Eric

Regards, Olaf

      reply	other threads:[~2014-03-19 22:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19 19:38 [PATCH] 3.8: access permission filesystem Olaf Dietsche
2014-03-19 21:13 ` Eric W. Biederman
2014-03-19 22:07   ` Olaf Dietsche [this message]

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=874n2tonas.fsf@olafdietsche.de \
    --to=olaf--list.linux-kernel@olafdietsche.de \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=serge.hallyn@canonical.com \
    /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.