Re: [PATCH 6/9] Add Documentation/namespaces/user_namespace.txt (v3)

[David Howells]

Serge Hallyn <serge@xxxxxxxxxx> wrote:

> To this new task, any resource belonging to the initial user namespace will
> appear to belong to user and group 'nobody', which are UID and GID -1.
> Permission to open such files will be granted according to world access
> permissions.  UID comparisons and group membership checks will return false,
> and privilege will be denied.

The last comma there is unnecessary, I think.  You might also want to say
'will fail' rather than 'will return false', but I'm not sure that sums it up
correctly.

> When a task belonging to (for example) userid 500 in the initial user namespace

Why switch to talking about 'userid'?  This should probably be 'UID'.

> Userid mapping for the VFS is not yet implemented, though prototypes exist.

Ditto.

> ... Therefore, attempts to exercise privilege to resources in, for instance,
> a particular network namespace, can be properly validated by checking whether
> the caller has the needed privilege (i.e.  CAP_NET_ADMIN) targeted to the
> user namespace which owns the network namespace.

That sentence looks rather clumsy.  I think you need to split the statement
from the example.

  Other namespaces, such as UTS and network, are owned by a user namespace.
  When such a namespace is created, it is assigned to [owned by? associated
  with?] the user namespace of the task by which it was created.  Attempts to
  exercise privilege in the new namespace are properly validated by checking
  whether the caller has the needed privilege targeted to [granted by?] the
  user namespace that owns the new namespace.  For instance, to use the
  resources in a network namespace, a check must be made that the caller has
  [has been granted?] the CAP_NET_ADMIN privilege.  This is done using the
  ns_capable() function.

You may want to list here what CAPs correspond to what namespaces.

> As an example, if a new task is cloned with a private user namespace but
> no

'not a' instead of 'no'?

> private network namespace, then the task's network namespace is owned
> by the parent user namespace.  The new task has no

Insert 'special' here?

> privilege to

s/to/over/ perhaps?

> the
> parent user namespace, so it will not be able to create or configure

'the'

> network devices

Insert 'therein'?

> .  If,

I don't think you need the comma here.  The 'instead' is the if condition.

> instead, the task were cloned with both private
> user and network namespaces, then the private network namespace is owned
> by the private user namespace, and so root in the new user namespace
> will have privilege targeted to

Interestingly, in these two paragraphs, you've used 'targeted to' in both
directions.

	whether the caller has the needed privilege (...) targeted to the user
	namespace

vs

	the new user namespace will have privilege targeted to the network
	namespace

You might want to consider changing one of them.  I would suggest 'granted by'
for the first and 'targeted at [users of]' for the second.

> the network namespace.  It will be able
> to create and configure network devices.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/