gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnue-dev] Appserver/Common Issues


From: Stanley A. Klein
Subject: Re: [Gnue-dev] Appserver/Common Issues
Date: Wed, 20 Nov 2002 21:51:02

Reinhard -

Perhaps I didn't make myself clear.  For your example you would have two
gfd files, one for those who are allowed access to the prices and one for
those who are not allowed access to the prices.  If the various other parts
of the form are the same for both users, the non-price parts could be in
one file for inclusion and the price display part in another file.  Then,
the two gfd files would be made up by "including" the non-price part in one
and the price and non-price parts in the other.  

Protecting the files would then depend on the operating system features.  I
assume that the rules for access are not scattered all over the place but
are organized according to a limited number of roles.  

In a system that uses access control lists, some static role structures can
be implemented through the ACL's.  I don't know how they work on all
systems, but I suppose some of the systems allow an access control group to
be defined, maintained in one list, and then the group name used as the
access control lists for the relevant files.  Then the price people would
be in one access control group and the non-price people in another.  The
price gfd file would have an ACL that refers to the price-allowed role
group and the non-price gfd file would have an ACL that refers to the
non-price-allowed role group.

In Security Enhanced Linux (which, as I said in another message, will be
optionally available in Linux Kernel 2.6 -- or could be implemented now
through kernel recompilation) the user login is not only User ID and
Password but also can be made to require Role.  (There are other Linux
access conrrol schemes that will also become available and have similar
capabilities.)  As I understand SE-Linux, a file is placed in a Domain that
can only be accessed by users currently logged in as specified Roles.  The
Domains, Roles, and Domain/Role file access rules are enforced by the
operating system just like the current Linux kernel enforces
user-group-other/read-write-execute access control.  The price people would
be assigned a Price Role and the Non-Price people a Non-Price Role.  The
the price gfd would be placed in the Price-Allowed Domain and the non-price
gfd in the Price-Disallowed Domain.

BTW, roles and domains are only part of the capabilities of SE-Linux.
There is a lot of other capability.

Transferring the ACLs, Domains, Roles, and other access control
functionality across a network should be a function of the operating
systems, not of the applications.

I don't see how maintaining such a system is any more difficult than
maintaining an equivalent system implemented a different way, such as
internally within appserver.


Stan Klein


At 04:09 PM 11/20/2002 +0100, Reinhard Mueller wrote:
>Am Don, 2002-11-14 um 19.20 schrieb Stanley A. Klein:
>> >3. different forms/reports/processes(GPD) for different users
>[snip]
>> 
>> The third point seems to me to be the easiest to do.  Simply provide
>> separate gfd and gpd files to the various users, protected by the operating
>> system access control capabilities.  Having a feature in Navigator that
>> provides a menu item greyed out with no functionality behind it might help
>> provide Navigator screens that seem to be the same (for training purposes)
>> but block certain functions that the particular user is not allowed to
access.
>
>This looks to me as if it would become unmaintainable.
>Say we have a company where several people may see purchase prices in
>various forms and reports, and other people may not. Would we have to
>double every single form and report that has the purchase price field?
>How would we apply an update of our application?
>
>> Another feature that might help in maintaining gpd, gfd, and grd files that
>> are separate for separate users would be an "include" capability in the
>> gfd, gpd, and grd processors.  That way the individual gfd and gpd files
>> could simply consist of include statements pointing to the files containing
>> the portions of the definition the user is allowed to access.
>
>Not sure whether such a system would be easily maintainable. Who decides
>what to put in which include file?
>
>IMHO both approaches fit small, non-widely deployed, mostly individually
>created applications. 
>
>Thanks,
>Reinhard





reply via email to

[Prev in Thread] Current Thread [Next in Thread]