Virtual Accounts


Contents:

Introduction

The issue of virtual or temporary accounts in PROOF is related to sand-boxing. PROOF queries need to be executed in a protected environment - which we call sandbox - essentially for two reasons:

  1. privacy of the results and/or activities;
  2. protection against undesired/unwanted actions from other users.
The second reason maybe the most relevant in HEP environments: we do not want that an uncontrolled action of one user screws up the work of others.

Currently sand-boxing is achieved using the the user UNIX account: at the end of session setup the user is logged into her/his account, and a dedicated PROOF area is created under user's $HOME and used to cache packages and macro files and store the results of queries.

This proved to work well; however, this requires an UNIX account for any potential user of the PROOF cluster.

The sandbox problem is not limited to PROOF, but is a general problem in GRID environments. Some solutions are being studied, ranging from temporary UNIX accounts created on the fly, to virtual machines used to create a user environment.

For the PROOF purposes the solution with temporary UNIX accounts seems appropriate. In the following we will outline the requirements.

Requirements

We assume that the sandbox service runs with su-privileges. This may be the PROOF daemon itself (as now) or an external agent devoted to sand-boxing.

The sand-boxing service should provide:

  1. possibility to create a user account to be assigned temporarily to a user authorized to use the facility (i.e. a user who proved to have the credentials to do so)
    1. what is needed, in fact, are a pair of (uid,gid) to be used to create a private space into an area devoted to user sandboxes
    2. the account should not be loggable from outside (i.e. shell /bin/false)
    3. the unique name of the user could be the 8 chars hash of the DN (Distinguished Name)
    4. it would probably good to have a unique group ID (group 'proof')
    5. the user ID should be chosen in a given (tunable) range
    6. the account should have the minimal privileges to run a query on the machine
  2. possibility to delete such accounts at any time
  3. dynamic mapping of users with their (existing, if the case) PROOF accounts

Things to look at before starting

  1. How DPM (Disk Pool Management, Jean-Philippe Baud) deals with virtual accounts
    1. Not much documentation, only a few slides
      1. look at the code
  2. GRID solutions for sandboxing, in particular those dealing with temporary UNIX accounts
    1. Predrag Bencig mentioned something that could perhaps be useful.

-- GerardoGanis - 03 Apr 2006

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2006-04-03 - GerardoGanis
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback