lkml.org 
[lkml]   [2011]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 6/9] Add Documentation/namespaces/user_namespace.txt (v3)
    Date
    Serge Hallyn <serge@hallyn.com> 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


    \
     
     \ /
      Last update: 2011-10-19 11:41    [W:0.136 / U:59.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site