I am able to understand the hierarchy structure. But have few questions.
If a record is inserted by 'Business Sales', it can read and modified by 'Software'. If the record is modified, then DB2SECURITYLABEL column will be updated to 'Software' and 'Business Sales' will loose access to the record.
Please correct me if i am wrong?

Can 'Software' insert a record on behalf of a 'Business Sales'? Is this possible?

Please only look at the question from an LBAC understanding perspective.
The users will be having access to the tables through Grant statements
only. This is not a practical scenario, just for understanding LBAC Tree
hierarchy and security labels.
Just look at them as security labels and not users.

I am not sure how else to put it, Man asking question itself is tough, how
am i going to understand? Please Help....

thats my point the method changes the ability of the function/process. You
need to define a specific process, then we can give detailed response.
Right now i see it as a 50/50 answer.

if you read my copy paste, you can see why i have askedd those questions,
specifically the middle to the bottom. you cant ask a generic question like
that... it depends on how you are accessing the data.

HTH

Fitz
Label-based access control (LBAC) overview

*What LBAC does*

Label-based access control (LBAC) greatly increases the control you have
over who can access your data. LBAC lets you decide exactly who has write
access and who has read access to individual rows and individual columns.

The LBAC capability is very configurable and can be tailored to match your
particular security environment. All LBAC configuration is performed
by a *security
administrator*, which is a user that has been granted the SECADM authority
by the system administrator.

A security administrator configures the LBAC system by creating security
label components. A *security label component* is a database object that
represents a criterion you want to use to determine if a user should access
a piece of data. For example, the criterion can be whether the user is in a
certain department, or whether they are working on a certain project.
A *security
policy* describes the criteria that will be used to decide who has access
to what data. A security policy contains one or more security label
components. Only one security policy can be used to protect any one table
but different tables can be protected by different security policies.

After creating a security policy, a security administrator creates objects,
called *security labels* that are part of that policy. Security labels
contain security label components. Exactly what makes up a security label
is determined by the security policy and can be configured to represent the
criteria that your organization uses to decide who should have access to
particular data items. If you decide, for instance, that you want to look
at a person's position in the company and what projects they are part of to
decide what data they should see, then you can configure your security
labels so that each label can include that information. LBAC is flexible
enough to let you set up anything from very complicated criteria, to a very
simple system where each label represents either a "high" or a "low" level
of trust.

Once created, a security label can be associated with individual columns
and rows in a table to protect the data held there. Data that is protected
by a security label is called *protected data*. A security administrator
allows users access to protected data by granting them security labels.
When a user tries to access protected data, that user's security label is
compared to the security label protecting the data. The protecting label
will block some security labels and not block others.

A user is allowed to hold security labels for multiple security policies at
once. For any given security policy, however, a user can hold at most one
label for read access and one label for write access.

A security administrator can also grant exemptions to users. An
*exemption*allows you to access protected data that your security
labels might
otherwise prevent you from accessing. Together your security labels and
exemptions are called your *LBAC credentials*.

If you try to access a protected column that your LBAC credentials do not
allow you to access then the access will fail and you will get an error
message.

If you try to read protected rows that your LBAC credentials do not allow
you to read then DB2? acts as if those rows do not exist. Those rows cannot
be selected as part of any SQL statement that you run, including SELECT,
UPDATE, or DELETE. Even the aggregate functions ignore rows that your LBAC
credentials do not allow you to read. The COUNT(*) function, for example,
will return a count only of the rows that you have read access to.

*Views and LBAC*

You can define a view on a protected table the same way you can define one
on a non-protected table. When such a view is accessed the LBAC protection
on the underlying table is enforced. The LBAC credentials used are those of
the session authorization ID. Two users accessing the same view might see
different rows depending on their LBAC credentials.

*Referential integrity constraints and LBAC*
The following rules explain how LBAC rules are enforced in the presence of
referential integrity constraints:

- *Rule 1*: The LBAC read access rules are NOT applied for internally
generated scans of child tables. This is to avoid having orphan children.
- *Rule 2*: The LBAC read access rules are NOT applied for internally
generated scans of parent tables
- *Rule 3*: The LBAC write rules are applied when a CASCADE operation is
performed on child tables. For example, If a user deletes a parent, but
cannot delete any of the children because of an LBAC write rule violation,
then the delete should be rolled-back and an error raised.

*What LBAC does not do*

- LBAC will never allow access to data that is forbidden by
discretionary access control.
Example: If you do not have permission to read from a table then you
will not be allowed to read data from that table--even the rows and columns
to which LBAC would otherwise allow you access.
- Your LBAC credentials only limit your access to protected data. They
have no effect on your access to unprotected data.
- LBAC credentials are not checked when you drop a table or a database,
even if the table or database contains protected data.
- LBAC credentials are not checked when you back up your data. If you
can run a backup on a table, which rows are backed up is not limited in any
way by the LBAC protection on the data. Also, data on the backup media is
not protected by LBAC. Only data in the database is protected.
- LBAC cannot be used to protect any of the following types of tables:
- A materialized query table (MQT)
- A table that a materialized query table (MQT) depends on
- A staging table
- A table that a staging table depends on
- A typed table
- LBAC protection cannot be applied to a nickname.

Let me rephrase the question.
A user U1 having security label 'Business Sales' inserts a record R1.
Another user U2 having security label 'Software' updates the record R1,
this will be allowed since 'Software' is in a higher level in the hierarchy
as per DB2LBACRULES. This will change the data in DB2SECURITYLABEL Column
of the table.
Now the user U1 with security label 'Business Sales' who originally
inserted the record R1, will lose access since it is now locked by a higher
security label.

There is a difference between updating data and updating the security label.
A row-level update by a user with superior hierarchical authority should not - in a sensibly designed system - update the label. The security label is not metadata and is independent of the data values.
If the documentation is a little dense, the simplest way to prove this is to run a quick test in a sandbox environment.
Caveat: I am talking theoretically, have never used LBAC, and probably never will now that RCAC is the new kid on the block; but did have to break my head studying it for the certification exams some years ago!

Alex, you hit the nail (right before I posted my own reply). I will post it anyway, just to support your view.

We struggled with practicality (or lack thereof) of LBAC since it was introduced in DB2 version 9. To me and some of my colleagues, LBAC does not look appealing (unless you work for DOD, where each row (record) is already assigned a security level/label outside of the database.

On the contrary, the newly introduced in version 10, row and column access control (RCAC) looks very promising. In fact, it's structured similarly to what we, poor application developers, were always trying to design while building our own authorization components in global (multi-regional, multi-functional) Web applications. And, of course, RCAC does it better than our home grown code.

Hi Alex,
I will try and let you know. Let us keep 2 days dead line; Do not hesitate
to reprimand/mortify me.

Hi Alex A,
I will surely look into RCAC as well.

Another thing that I could not understand was, why should we grant read
access and write access on security labels.
Will DB2LBACRULES not handle that. I assume it is for preventing write
access to people higher in hierarchy. Confirm please.
Also if there are existing records, can we update DB2SECURITYLABEL column
alone for them.

Whoever you work for, chances are it is a commercial company, not the CIA.
One reason, apart from obsolescence, that I did not experiment myself is that LBAC is separately licenceable. Have you actually paid for a license or are you using a try-and-buy version?
In answer to your questions and from memory - please confirm by independent research:
A. The row is secured by a security label. You need both the table permission and the security label to access that row.
B. DB2LBACRULES is primarily for restricting access to users lower in the hierarchy, not those higher in that hierarchy.
C. I think you can update a security label only by dropping it and re-declaring it.

I did try my level best. I used a TREE component with 3 levels -
org-->mgr-->rep
3 users org,mgr,rep were granted all access for security labels org,mgr,rep
respectively.

LBAC did allow a user at higher level to access,modify and insert the
records of lower level including the update of security label column.
Also, org can update/insert a record with a lower security label as well.

I think the key to crack LBAC is to understand the LABEL and how they are
compared.
That helped me a lot in answering most of the questions with repeated
reading of Info Center.

A label looks like below :
(elem1,elem2):(elem3,elem4,elem5):elem6

The above label is protected by 3 components.
(elem1,elem2) are two elements of first component
(elem3,elem4,elem5) are three elements of second component
elem6 is element of third component.

Each component may be of SET/ARRAY/TREE. You have to compare security label
held by a user with protected columns security label to figure out if you
have access to it or not along with traditional table privileges.

LBAC did work on Express - C. I am not sure of licensing here. I just tried
it,worked and stopped using it. Have learned a new thing. That is all.