Morrison, R., Brown, A. L., Connor, R. C. H., Cutts, Q. I., Kirby, G. N. C., Dearle, A., Rosenberg, J. and Stemple, D. "Protection in Persistent Object Systems", Security and Persistence, pp.48-66, 1990.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... are mostly used in operating systems [4] 6] 37] It is also common to see arguments to the effect that information hiding is a form of security mechanism [17] Morrison et al. argued that although objects may be used to implement capabilities, they are not in themselves equivalent to capabilities [29]. On a more general note the object oriented paradigm was conceived to foster good software engineering principles. Trying to contort its features into security mechanisms is bound to fail. Our claim is that object oriented programs are not more secure than programs written in any other paradigm. ....

R. Morrison, A. Brown, R. Connor, Q. I. Cutts, G. Kirby, A. Dearle, J. Rosenberg, and D. Stemple. Protection in Persistent Object Systems, In Security and Persistence, pages 48--- 66. Springer-Verlag, 1990.

....on other machines to be addressed in the same manner as local data [9, 10, 12, 25, 26] Protection of data: A protection mechanism must be provided to protect data from accidental or malicious misuse. In persistent systems this is typically provided via the programming language type system [20], through data encapsulation [17] using capabilities [6] or by a combination of these techniques. The Grasshopper project seeks to provide a mechanism that provides resilience as an intrinsic attribute of a distributed, orthogonally persistent operating system. 1.1. Grasshopper The ....

Morrison, R., Brown, A. L., Connor, R. C. H., Cutts, Q. I., Kirby, G. N. C., Dearle, A., Rosenberg, J. and Stemple, D. "Protection in Persistent Object Systems", Security and Persistence, pp.48-66, 1990.

....provide a protection mechanism could result in erroneous processes corrupting data owned by other users. Therefore a protection mechanism must be provided to protect data from accidental or malicious misuse. In persistent systems this is typically provided via the programming language type system [29], through data encapsulation [26] using capabilities [11] or by a combination of these techniques. To date, most persistent systems, with a few exceptions [6, 9, 34] have been constructed above conventional operating systems. Implementors of persistent languages are invariably forced to ....

....of exceptions and deletion of loci. In conventional operating systems these access controls are usually provided by the file system interface. This is clearly inappropriate for Grasshopper. In several existing persistent systems protection is provided via the programming language type system [29] or through data encapsulation [26] Grasshopper is intended to support multiple languages and therefore cannot rely solely on a type system. The protection abstraction provided by Grasshopper is the capability [11] Capabilities were first proposed by Dennis and Van Horn [10] and have been used ....

Morrison, R., Brown, A. L., Connor, R. C. H., Cutts, Q. I., Kirby, G. N. C., Dearie, A., Rosenberg, J. and Stemple, D. "Protection in Persistent Object Systems", Security and Persistence, Workshops in Computing, Springer-Verlag, pp. 48-66, 1990.

....provide a protection mechanism could result in erroneous processes corrupting data owned by other users. Therefore a protection mechanism must be provided to protect data from accidental or malicious misuse. In persistent systems this is typically provided via the programming language type system [27], through data encapsulation [25] using capabilities [12] or by a combination of these techniques. To date, most persistent systems, with a few exceptions [7, 10, 32] have been constructed above conventional operating systems. Implementors of persistent languages are invariably forced to ....

....of exceptions and deletion of loci. In conventional operating systems these access controls are usually provided by the file system interface. This is clearly inappropriate for Grasshopper. In several existing persistent systems protection is provided via the programming language type system [27] or through data encapsulation [25] Grasshopper is intended to support multiple languages and therefore cannot rely solely on a type system. The protection abstraction provided by Grasshopper is the capability [12] Capabilities were first proposed by Dennis and Van Horn [11] and have been used ....

Morrison, R., Brown, A. L., Connor, R. C. H., Cutts, Q. I., Kirby, G. N. C., Dearle, A., Rosenberg, J. and Stemple, D. "Protection in Persistent Object Systems", Security and Persistence, pp.48-66, 1990.

....was originally planned as part of the PISA project [1] with the major goal of constructing a self contained, orthogonally persistent system. The system was also intended as, or turned out to be, a testbed for experiments in: type systems for data modelling [2 7] bulk data [8, 9] and protection [10, 11]; programming language implementation [12, 13] binding mechanisms [14 17] programming environments [17 20] system evolution [21 23] concurrency control and transactions [24 27] object stores [26, 28 35] and software engineering tools [36 39] The Napier88 system consists of the Napier88 ....

....the protection of data, controlled system evolution, concurrency control and transactions, and programming within the persistent environment, including hyper programming. The justification of the persistence design decisions is given in [53] and the advantages of the abstraction outlined in [4, 11, 15, 18, 34, 54 63]. 2 Controlling Complexity 2.1 Language Design McCarthy [64] van Wijngaarden [65] Strachey [66] and Tennent [67] all observed that expressive power in programming languages could be gained by separating the underlying concepts and allowing them to be combined by powerful composition rules. ....

[Article contains additional citation context not shown here]

Morrison R, Brown AL, Connor RCH et al. Protection in Persistent Object Systems. In: Rosenberg J, Keedy JL (ed) Security and Persistence, Proc. International Workshop on Security and Persistence, Bremen. SpringerVerlag, 1990, pp 48-66

....Large bodies of data are inherently valuable, and must be protected against accidental or deliberate misuse. This is true in both persistent and non persistent programming systems. However, protection mechanisms in a persistent system may be modelled quite differently from a non persistent system [MBC90, CDM90]. As all data within a persistent system are subject to type system constraints, no unlawful access to the data may occur except in the event of system failure. This gives the property of type safety to permanent data, which can not be achieved in a non persistent system. A further effect of the ....

....technology. This means that access protection and software constraints may be programmed as suitable for the individual data. A number of different language mechanisms may be used to protect permanent and shared data, including subtype inheritance, procedural encapsulation, and abstract data types [MBC90]. 1.5.2.2 Viewing mechanisms The protection of data in database systems is normally achieved by integrity constraints and viewing mechanisms. In a persistent system, however, such mechanisms do not need to be specially provided as they may be programmed within a persistent programming language. ....

[Article contains additional citation context not shown here]

R. Morrison, A.L. Brown, R.C.H. Connor, Q.I. Cutts, A. Dearle, G. Kirby, J. Rosenberg and D. Stemple "Protection in Persistent Object Systems" In "Security and Persistence", J. Rosenberg and L. Keedy (eds), Springer-Verlag ( 1990 ) pp 48 173

....on weather features. The technique uses the language type system to give users access to handles which refer to the underlying data but have strictly limited functionality. Although achieved in a different way, the modelling ability is as powerful as, and similar to, that of capability systems [Morrison et al. 1990]. Both apply protection to the access paths to the data, rather than to the data itself, in order to retain flexibility, and both ultimately rely on some form of user authentication. 2.4 Co ordinate Systems Independent co ordinate systems are a special case of overlapping objects that require ....

Morrison, R., Brown, A.L., Connor, R.C.H., Cutts, Q.I., Kirby, G.N.C., Dearle, A., Rosenberg, J. and Stemple, D. (1990) Protection in Persistent Object Systems. In J. Rosenberg and J.L. Keedy (ed) Security and Persistence. Springer-Verlag, pp. 48-66.

....reconstruct a graph before output and after input. Thus the size of the application code is reduced thereby producing savings throughout the software life cycle of the application. The third benefit of persistent systems is that a single model of protection may operate over the whole environment [Morrison et al. 1990]. In most programming languages the simplest way to break the protection system is to output a value as one type and input it again as another. Thus security is lost over the persistent store. Using a single enforceable model reduces complexity while increasing the protection as its type checking ....

....A sequence of examples of declarations is given to convince readers that programmer defined types provide a convenient notation and an extensible descriptive system of comparable power to many data models. The examples are written in a style close to the Napier88 notation [Morrison et al. 1989, Morrison et al. 1990] with the assumption that structural equivalence checking is in operation [Connor et al. 1990] A new type name is introduced with a notation such as the following: type Count is int which declares Count as a type name and makes it a synonym for the type int assumed already defined. Similarly, ....

[Article contains additional citation context not shown here]

Morrison, R., Brown, A.L., Connor, R.C.H., Cutts, Q.I., Kirby, G.N.C., Dearle, A., Rosenberg, J. & Stemple, D., 1990. Protection in Persistent Object Systems. In Security and Persistence, Rosenberg, J. & Keedy, J.L. (ed.), Springer-Verlag, Proc. International Workshop on Security and Persistence, Bremen, 1990 pp 48-66.

....the system is independent of their other properties. A single programming language mechanism handles the longevity of all data items from micro seconds to years. 3 The benefits of orthogonal persistence are well documented [ACC82,ABC 83, ABC 84,AM85,AMP86,AB87,MBC 87,Wai87,AM88,Dea88,Bro89,MBC 90,Con 91,Weg90] A major advantage of persistent systems is seen in the removal of complexity. An inherent difficulty associated with the programming of data intensive applications is the understanding of the mappings between the real world and the computational models. The programmer of an ....

....locations. The component space can be partitioned by the use of environments as a structuring tool in the persistent store as described in Section 2.3.1. The effect is identical to that shown in Figure 2.6. There are many ways in which locations may be protected within a strong type system [MBC 90] two are described here. The first involves the drop language construct, described by example in Figure 2.14. use PS( with exampleEnv : env in drop dialogue from exampleEnv Figure 2.14 Dropping an access path. This finds the exampleEnv environment in the root of the store and drops the binding ....

R. Morrison, A.L. Brown, R.C.H. Connor, Q.I. Cutts, G.N.C. Kirby, A. Dearle, J. Rosenberg and D. Stemple "Protection in Persistent Object Systems" In Security and Persistence, Springer-Verlag (1990) pp 4866.

....time because there is no need to write code to flatten and rebuild data structures for storage in files [4] since all data resides in the same store a single model of protection may be used. This is in contrast to the multi level protection involving processes and files on conventional systems [19]. These advantages are not achieved without a cost. In particular persistent systems have a considerable impact on memory management, protection and distribution. Most research groups working in this area have concentrated on producing persistent programming languages. These languages provide ....

Morrison, R., Brown, A. L., Connor, R. C. H., Cutts, Q. I., Dearle, A., Kirby, G., Rosenberg, J. and Stemple, D. "Protection in Persistent Object Systems", Proceedings of the International Workshop on Computer Architectures to Support Security and Persistence of Information, Springer-Verlag, Bremen, Germany, pp. 48-66, 1990.

No context found.

Morrison, R., Brown, A.L., Connor, R.C.H., Cutts, Q.I., Kirby, G.N.C., Dearle, A., Rosenberg, J. & Stemple, D. "Protection in Persistent Object Systems". In Security and Persistence, Rosenberg, J. & Keedy, J.L. (ed), Springer-Verlag (1990) pp 48-66.

No context found.

Morrison, R., Brown, A.L., Connor, R.C.H., Cutts, Q.I., Kirby, G.N.C., Dearle, A., Rosenberg, J. & Stemple, D. "Protection in Persistent Object Systems". In Security and Persistence, Rosenberg, J. & Keedy, J.L. (ed), Springer-Verlag (1990) pp 4866.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC