\item \verb'LOG_WMS_EVENTS'
\item \verb'LOG_CE_EVENTS'
\item \verb'LOG_GENERAL_EVENTS'
+\item \verb'GRANT_OWNERSHIP' (\LBver{3.0})
\end{itemize}
The first action disables all authorization checks. The next four categories concern with acquring data from the \LB
sent from any place on the grid, namely \verb'CURDESC', \verb'USERTAG', and
\verb'CHANGEACL'. It is important to understand that these access control
rules provides additional level to the existing authorization routines.
-Especially, being granted the \verb'LOG_GENERAL_EVENTS' right is not sufficient to
-change ACLs on jobs of other people, etc.
+In particular, being granted the \verb'LOG_GENERAL_EVENTS' right is not sufficient to
+e.g. change ACLs on jobs of other people and obtain an access to the job information.
+
+As of \LBver{3.0} it is possible for the job owner to hand over the ownership
+of the payload to another user, which eases handling \eg of pilot jobs. In
+order to set the payload owner, the job owner must log a
+\verb'GrantPayloadOwnership' event, where the identity of the new
+payload owner is introduced. The event can only originate from loggers
+described by the \verb'GRANT_OWNERSHIP' category of the policy file. More
+information and an example of ownership setting is given in the \LB Users'
+guide.
The \LB policy is specified in a policy configuration file that must be given
in the server configuration. Specifying the policy file also triggers the
subject = ".*"
}
}
+ action "GRANT_OWNERSHIP" {
+ rule permit {
+ fqan = "/VO/Pilot_job_factory"
+ }
+ }
}
\end{lstlisting}
Certificate Revocation Lists or syslog messages. For a detailed description see
\cite{LB4CRL}.
-
+\subsubsection{Controlling access to job information}
+\label{sec:job-authz}
+Access to information about a job subjects to strong access control
+mechanism. By default, only the job owner is allowed to access the
+information about their jobs. There are, however, means how additional
+rights can be granted to other persons. The \LB server administrator can
+specify a server-level policy, which grants specific rights to all jobs
+stored in the server, please refer to the \LB Administrators' guide for
+more information.
+
+Besides the server-wide configuration, a job owner can also grant access to
+their jobs to other users. Each job can be assigned an Access control list
+(ACL), which specifyies which users are allowed to work with the job
+information. If a job owner wants other users to be allowed to obtain
+information about their job, they provide an ACL rule granting \verb'READ'
+access for the users. The users can be identified either by their X.509
+subject name or their VOMS attributes. As of \LBver{3.0}, it is also
+possible to grant a \verb'TAG' right, which allows multiple users to add
+user tags to the same job. The current ACL of a job is returned as a part
+of the job status. Management of the ACL entries is done using logging a
+special \LB event in a standard way (see \ref{e:change-acl} for particular
+examples).
+
+Starting from \LBver{3.0}, it is also possible to specify the owner of the
+actual payload of a job. The feature has been introduced for better support
+of multi-user pilot jobs, where the pilot submitter differs from the owner
+of actual payload. In order to set the payload owner, the job owner has to
+log a \verb'GrantPayloadOwnership' event which specifies the subject owner of the
+payload owner. This event is supposed to come from a pilot job factory
+which monitors the pilot jobs and keeps an overview about when a particular
+payload is started. The new payload owner has to confirm the transition
+with a \verb'TakePayloadOwnership' logged to the job using his or her
+credentials. The payload and job owners have the same rights to the jobs,
+they both can query the job, etc. The identity of the current payload owner
+is returned as part of the job status information.
\subsubsection{Example: Changing Job Access Control List}
\label{e:change-acl}
-In order to change the Access Control List (ACL) for a job, a special event
+In order to change the Access Control List (ACL) for a job (see also \ref{sec:job-authz}), a special event
\verb'ChangeACL' is used. This event can be logged by the job owner using the
\verb'glite-lb-logevent' command (see also Sect.~\ref{glite-lb-logevent}).
The general template for changing the ACL is as follows:
\verb'DN', \verb'GROUP', and \verb'FQAN' can be given to
specify X.500 name, VOMS group, or FQAN, respectively \\
\verb'<permission>' & ACL permission to change, currently only \verb'READ' is
- supported. \\
+ supported. Starting from \LBver{3.0}, the permission \verb'TAG' can
+ also be used.\\
\verb'<permission_type>' & Type of permission requested. \verb'ALLOW' or
\verb'DENY' can be specified. \\
\verb'<operation>' & Operation requested to be performed with ACL. \verb'ADD'
\begin{verbatim}
glite-lb-logevent -e ChangeACL -s UserInterface -p -j <job_id> \
--user_id '/VOCE/Role=Administrator' --user_id_type FQAN \
- --permission READ --permission_type ALLOW \
+ --permission TAG --permission_type ALLOW \
--operation ADD
\end{verbatim}
\input log_usertag.tex
\input change_acl.tex
+
+\subsubsection{Example: Setting payload owner}
+\label{e:payload_owner}
+
+In order to change the owner of the payload (see also \ref{sec:job-authz}),
+a pair of \LB events is used. In order for a job owner to specify a new
+owner of the payload, the \verb'GrantPayloadOwnership' event is used, \eg:
+
+\begin{verbatim}
+glite-lb-logevent -e GrantPayloadOwnership -s UserInterface -j <job_id> \
+ --payload_owner <subject_name>
+\end{verbatim}
+
+where
+
+\begin{tabularx}{\textwidth}{>{\texttt}lX}
+\verb'<job_id>' & specifies the job to change access to\\
+\verb'<subject_name_id>' & specifies the X.509 subject name of the new payload user. \\
+\end{tabularx}
+
+The new payload owner confirm they accept the ownership using the
+\verb'TakePayloadOwnership' event. Note that this event event must be
+logged using the credentials of the new user:
+
+\begin{verbatim}
+glite-lb-logevent -e TakePayloadOwnership -s UserInterface -j <job_id>
+\end{verbatim}
git://scientific.zcu.cz / jra1mw.git / commitdiff