system, and make the native file system detached from local operating systems .... such as Public Key Infrastructure and digital signature. Our method employs a ...
VegaFS: A Prototype for File-Sharing Crossing Multiple Administrative Domains Wei Li, Jianmin Liang, Zhiwei Xu Institute of Computing Technology, Chinese Academy of Sciences Beijing 100080, China {liwei, ljm, zxu}@ict.ac.cn Abstract Accessing remote resource is a principal challenge of grid computing. For wide-area file sharing, a most difficult problem is the inability to access files distributed in different administrative domains. In this paper, we propose a file system architecture called VegaFS, which is detached from administrative domains entirely and provides cross-domain file access abilities. The main idea is to adopt public keys in native file systems and transfer the management work of administrator to trusted certificate authorities (CAs). Compared with other systems, VegaFS provides several benefits, such as gridwide unique user identities, cross-domain file access capability, scalabilities, fine-grained dynamic access control and better securities.
1. Introduction Sharing file resources in wide areas is an important issue for grid systems. A grid file system should meet the requirements such as cross-domain file access capability, scalability, security, single name space, and high performance. Current research work focuses on various aspects of these requirements [2,3,6,9,15], among which providing cross-domain capability is a major challenge. The obstacles of implementing a grid file system come from the requirements of the Grid problem [12], defined as coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations. This definition indicates that one important feature of a grid file system is the ability to cross multiple institutions or administrative domains. When solving the cross-domain problem, we must consider the following issues carefully: How to represent file users uniquely? What is the relationship between a grid file system and administrative domains in grid nodes? How to control file access in a grid file system? In VegaFS, we adopt the following strategies to answer the above three questions: Adopting public keys as global user identities. In VegaFS, we adopt the users’ public key as his global
user identity, which replaces the current UID in traditional operating systems. The global uniqueness of this user identity is guaranteed by PKI [18] or GSI [10] infrastructure. Detaching native file systems from administrative domains. Most native file systems are bound to a local administrative domain, as the UID/GID identifying the file owners are centrally managed by the local operating system kernel. In VegaFS, we implant the global user identity into the native file system, and make the native file system detached from local operating systems entirely. Consequently, file users can transparently access multiple VegaFS file servers without creating an account (a UID) for each file server. The work of user management, such as user creation and user identity verification, can be fulfilled by third-party certificate authorities instead of the local administrative domains. Using peer-to-peer authorizations for access control. A file owner can share his file with other users by means of issuing an authorization certificate. This peer-to-peer authorization mechanism can implement a fine-grained, dynamic access control mechanism for VegaFS. The paper is organized as follows: Section 2 introduces the background and related work on grid file systems. Sections 3 and 4 describe the architecture and implementations of VegaFS. Section 5 compares performance between VegaFS and other network file systems. Section 6 offers several concluding remarks.
2. Backgrounds and Related Work In traditional operating systems, the users and the resources are coupled closely with local administrative domains. The native file system authenticates a user with a local user identity, and authorizes file access rights according to local access control information such as an access control list (ACL). When file resources are shared across administrative boundaries, this scheme fails because other administrative domains have no knowledge of the recipient’s identity. The principal mission of a grid file system is to provide cross-domain access capability.
This work is supported in part by the National Natural Science Foundation of China (Grant No. 69925205), the National High-Tech R&D 863 Program of China (Grant No. 2002AA104310), and the Chinese Academy of Science Overseas Distinguished Scholars Fund (Grant No. 20014010). Proceedings of the IEEE International Conference on Cluster Computing (CLUSTER’03) 0-7695-2066-9/03 $17.00 © 2003 IEEE
We define cross-domain capability to means that a user with a globally unique identity can access file resources distributed in different domains without knowing the existence of these domains. This definition implies two essential features for a grid file system: A file user should have a grid-level unique identity. The user and the file themselves should no longer be bounded to certain administrative domains. In other words, administrative domains should be transparent to file users. A file user does not need to know the hosting domain of his files. In an open grid environment, multiple domains should be eliminated at the grid level. Several research projects have proposed different solutions to provide for the above two features. Global user identity and identifying user’s resources by public keys are also used in previous research work. SFS [19] separates key management from file systems by selfcertifying pathnames, which is the hash of the server’s location and server’s public key. LegionFS [15] uses the object-oriented technology to encapsulate the file resources in a global namespace and embeds the public key into the object, which enables users to access all files of LegionFS in a secure manner. OceanStore [17] denotes files and directories by objects, where every object is identified by a global unique identifier (GUID). The naming of GUID adopts the method of SFS, the hash of the object’s name and object owner’s public key. Self-certifying pathname of SFS means users have to first find a self-certifying pathname, and then get the remote server’s location from it. Self-certifying pathname contains the hash of file server’s public key, whose main function is to authenticate file server to users, and does not implement fine-grained file access control. AFS [16] uses multiple authentication servers to maintain a global user management system, which enables a file user to access multiple file servers with a token scheme. However, this method still belongs to centralized user management, and has the problem of system bottleneck. PUNCH [9] uses the shadow account and NFSforwarding proxy technology. It allows a client executing on a compute server to access files stored in another domain. Encrypting file systems like CFS [4] place great emphasis on maintaining the privacy of the user information by encrypting the file names and their contents. The limitation of such systems is that sharing is particularly difficult to implement. OceanStore also identifies resource owners by public keys. The major difference between VegaFS and OceanStore is as follows. VegaFS identifies the ownership of files by means of the tight binding between file owners’ public key and their files. This binding is implemented by extending the native file system, not by any middleware such as objects. Therefore, this binding does not affect the original applications of native file system. OceanStore encapsulates the file resources as objects. The file
operations are also based on objects. File user can only interact with objects but not files. They can be viewed as a new object layer added between native file systems and file users. The traditional semantics of the UNIX file system cannot easily be supported. OceanStore is mainly used to implement a file storage system, not a file system used by grid computing. Some peer-to-peer file-sharing systems such as Napster [20] and Gnutella [14] have the same problems. LegionFS and OceanStore organize file resources as objects. The Legion system [15] copy files into Legion space and supports global data access. File users can access data only by specialized Legion I/O methods. This limits the deployment and utilization of Legion system, as programmers still want to access files via the traditional file access semantics. Farsite [1] is a distributed file system, which aims at obtaining security and scalability in an untrusted environment. Similar to VegaFS, Farsite uses public keys to identify users and servers. However, Farsite maintains the access control information at the directory level, not at the file level, by including the public keys of all users in the directory metadata. This may make the directory a performance bottleneck. The above network file systems are mostly built on existing administrative domains, without considering the separation of native file systems and administrative domains. In most cases, they map a global user identity to a local UID after authentication. This could cause a security problem: multiple global users are mapped to a single local user, and the files of one user may be improperly shared by another, unauthorized, user. In VegaFS, we draw ideas from security technologies, such as Public Key Infrastructure and digital signature. Our method employs a user’s public key as his global identity and implants the public key into the file itself. The work of file access control is transferred from local domains to certificate authorities and native file systems; files are not managed by the local domains any longer. This method embodies the physiology of grid described in [11] that all resources are abstracted as services. From the viewpoint of users, they can access file resources transparently without knowing the existence of administrative domains. All that a user can view is a set of grid services managing file resources. We adopt a peer-topeer authorization method to provide a flexible, dynamic, fine-grained file access control mechanism. In addition, we use the following principles to guide the design of VegaFS: no centralized control, no or little modification to legacy applications, transparent file access and little impact on performance. Putting together, VegaFS could bring the following advantages: cross-domain file sharing, fine-grained dynamic access control, scalability and Security. In addition, we implement the functionalities of VegaFS at the operating system layer, which eliminates the additional overhead brought by a middle layer.
Proceedings of the IEEE International Conference on Cluster Computing (CLUSTER’03) 0-7695-2066-9/03 $17.00 © 2003 IEEE
3. VegaFS Architecture 3.1. Architecture Overview As illustrated in Figure 1, there are three basic components in VegaFS: file users, native file systems, and certificate authorities. A file user in VegaFS is different from that in traditional file systems. The role of a file user is to access his files or authorize access right to other users. A file user must have a global unique identifier. If a user wants to share the files of other users, he should also get the access right granted by the file owners. File Users
There are several methods proposed by different research projects, as mentioned in Section 2. In VegaFS, we adopt the user’s public key as his global identity, which meets the above requirements. The first requirement is easy to meet, because the public key issued by a certificate authority can guarantee its global uniqueness. For the second requirement, the PKI architecture itself uses a decentralized mechanism to manage the user’s certificate, which also provides good scalability to VegaFS. In addition, PKI can guarantee the global user identity hard to forge. Combined with digital signature, VegaFS can establish a trusted communication channel between file users and native file systems.
3.3. Native File System Extensions Certificate Authorities
Native File Systems
Figure 1. Basic Components in VegaFS Due to the distributed and global properties of PKI, we adopt it as a global user management system, which is responsible for operations such as registration, certificate issuing and authentication. The most important function is to authenticate the validity of a certificate. When a file user accesses a file server in VegaFS, the file server should verify whether a trusted certificate authority issued the user’s certificate. Native file systems are mainly responsible for file access control. When a user accesses a file, the file server should check whether the user is trustable, whether this user is the file owner, and whether this user has the proper access right. In VegaFS, the native file system (we call it as a VegaFS server) will check the user’s certificate directly without the intervention of the local domain. A VegaFS server trusts a third-party certificate authority and depends on this certificate authority to authenticate the validity of a certificate. In addition, it will check whether a file access request has the permitted access right after that request passes through the authentication process.
When we adopt the public key as the global user identity, another question comes up: how can this identity be embodied in native file systems? Our solution is to extend the function of existing native file systems. We implant the global user identity into the file itself, which enables native file systems detached from local administrative domains. We also implement the file access control in the native file system itself. In traditional operating systems, this task is usually accomplished by the operating system kernel. Figure 2 shows our extension to native file systems, which includes two parts: the public key in the file header and the access control module. For each file in VegaFS, its header should contain a public key that indicates the owner of this file. The native file system also has an access control module that will check whether a file access request has the right to access a file. The file access request will contain a digital signature signed by the requester, to show that an access request surely come from the requester. Our methods can provide two merits for file sharing in a grid. Firstly, our extension reduces the hierarchy levels between file users and files, enables file users interact with files servers directly without the intervention of administrative domains, and avoids the overhead brought by a middle layer. File Access Request
Signature
3.2. Global User identity In traditional operating systems, user identities such as UID and GID are meaningful only in a local domain. To realize the cross-domain capability, the representation of users should be globally meaningful. We consider the following requirements: (1) The identity should be globally unique; (2) The identity should not be centralized maintained; (3) The identity should be hard to forge.
File Header
File Data
Access Control
Public Key Native File System Extention
Native File System
Figure 2. The Extension to Native File Systems
Proceedings of the IEEE International Conference on Cluster Computing (CLUSTER’03) 0-7695-2066-9/03 $17.00 © 2003 IEEE
3.4. Peer-to-peer Authorizations In VegaFS architecture, there is no central management of file users. The access control information is not pre-stored in a central location. When a file user wants to share another user’s file, he needs to contact the file owner to obtain the file access right. A file owner can issue the file access right on demand and dynamically. On demand access control. In traditional file systems, the file owners predefine the file access control. In most cases, the file owners should presuppose all possible circumstances that who can share his files. Then a domain administrator, who will strictly follow the rules set by file owners, will accomplish the access control work. In a grid environment, it is hard to determine all possible operations in advance. The file users should interact with each other in an on demand manner when sharing files. Fine-grained file sharing. In traditional file systems, fine-grained file sharing can be achieved by centralized access control mechanisms such as access control lists. However, in a grid, it is difficult to maintain such a centralized list. With a peer-to-peer mechanism, each file owner can maintain the access control information of his own files, to provide for fine-grained file sharing.
3.5. Key Operations in VegaFS In traditional operating systems, file owners hand file access control tasks to a superuser of a local domain. In VegaFS, this task is fulfilled by file owners instead. The sharer’s operations in VegaFS mainly involve the authorizations between file owners and file sharers. A file owner’s operations are changed in two aspects: File create process. In this process, there are two important operations: authenticating a file user and implanting a public key into a file header. The first operation is to determine the authenticity of a file user. The second operation is to mark up the file owner. This process is similar to that in traditional file systems except for using the public key as the user identity. File access process. In this process, VegaFS can build a trusted relation between file owners and files. When a file user accesses his files, he should send a request containing his digital signature. The VegaFS file server then uses the public key stored in that file to verify the validity of the request, and guarantees the file owner is unforgeable. Figure 3 illustrates the process that user B accesses a file owned by user A. In the native file system, a file of user A is attached with the public key of user A. User B first gets the location of the file by other approaches such as from a global file directory. Then, when user B wants to access that file, he should first get an authorization certificate issued by user A with the encrypted
information about the access right permitted by user A. Then user B sends a file access request with this authorization certificate to the file server. The access control module in this server will use the public key of user A to check the validity of this request. 1
User B
User A 2
Signature of A
Access Control
File Header
Public Key of A
File Data
Native File System
Figure 3. User B accesses a file owned by user A
4. Implementations We describe an implementation of VegaFS based on NFS [21], focusing on two major components in VegaFS: the VegaFS Client (VC) and VegaFS Server (VS).
4.1. Public Keys versus UIDs When we implement VegaFS, one difficult problem is how to deal with the relationship between user’s public keys in VegaFS and UIDs in traditional operating systems. If we modify the native file system and replace UID with public keys completely, it will cause a serious problem: all user-level software has to be modified, such as shells, utilities, and applications. We choose to make the native file system of VegaFS supporting legacy applications. We use two methods to fulfill this requirement. Firstly, we make global user identities coexist with UID in traditional operating systems. That is, we use the extend attribute of each file to store the file owner’s public key. At the same time, this method should guarantees the UID of this file unchanged. Secondly, VegaFS uses a special directory invisible to local administrative domains and legacy applications. This directory is maintained by a VegaFS server, which uses extend attribute of files in this directory to accomplish the task of access control.
4.2. File Access and Access Control In VegaFS, a user visits VS through VC, which should be trusted by this user completely. On the other hand, VC should also submit the user’s global identity to VS in each file access request.
Proceedings of the IEEE International Conference on Cluster Computing (CLUSTER’03) 0-7695-2066-9/03 $17.00 © 2003 IEEE
4.2.1. CRUL and SRUL We modify the mount system call to store the user’s global identity in VC in advance. When a user sends a file access request, he needs not to send his certificate to kernel via NFS client APIs, and VC will retrieve his certificate from the kernel. This method can guarantee compatibility with NFS client APIs and all existing applications running on NFS client need not be modified. In addition to store the global user identity in VC, we draw some ideas from Diffie-Hellman [7], by which VC needs not to send global user identities any longer. In [7], a simple string of characters instead of an operating system specific integer identifies a client, which is known as the netname of the client. The major benefit of netname is that there are no needs to send global user identities in each file access request, as VC can dynamically produce its own netname and VS can produce this netname just based on existing information of a networked request. We devise a client-side data structure called ClientRegistered-User-List (CRUL) and a server-side data structure called Server-Registered-User-List (SRUL). The function of CRUL is to map users’ netnames to their private keys. When sending a request to VS, VC will first fetch a private key in CRUL according to current user’s netname to generate a digital signature. CRUL will also collect information about users, such as certificates, private keys, UIDs, etc, and it is indexed by the user’s netname. SRUL, on the other hand, is used to map users’ netnames to their public keys. When receiving a request from VC, VS will fetch a public key in SRUL according to current user’s netname to check the validity of the signature in the request. In addition, CRUL and SRUL support mapping multiple public/private keys to one netname when multiple clients sharing a same netname.
4.2.2. File Access Process of VegaFS When a user accesses a file, he should first execute a special client-side program to send his certificate and private key into CRUL. Then VC verifies this certificate through a trusted CA. If the certificate and private key are valid, VC will store it in CRUL. When the user issues a mount system call to remote VS, VC will form the netname of user according to user’s UID and domain name of the user. Then VC gets the information from CRUL based on the user’s netname. Finally, VC dynamically submits the user’s certificate to VS. When VS receives the user’s certificate, it verifies this certificate according to the signing CA in that certificate. If it is valid, VS allows the user mount the exported directory. Then VS finds the UID of requester and the IP of client from mount request to form the netname of user. VS stores this user’s certificate in SRUL according to the netname.
Having mounted the remote VS successfully, the user can access the files in VS. VC retrieves the user’s private key from CRUL, creates a digital signature according to the content of RPC packet, and appends this signature at the end of RPC packet. When VS receives the RPC packet, it retrieves the user’s public key from SRUL and verifies the signature of RPC packet; if it is valid, VS can believe this packet is surely issued by the owner of this public key. The RPC call is forwarded to the native file system. When a user creates a file, the public key and the useful information of the user will be written in the file header. When a user accesses a file such as READ request, VS will compare the file owner’s public key with the public key of the user in SRUL; if they are identical, we can educe that the user is the file owner. If they are different, VS will startup the authentication procedure to check the authorization certificate in this request and make sure whether the request has the right to access this file.
4.2.3. RPC-based Security of VegaFS One approach to provide secure access in an open network is to set up a secure connection between a client and a server. A good example for secure communication is the secure socket layer (SSL) [13], which provides security for any TCP connections. The most obvious problem with connection-based security is that it cannot protect the traffic over a connectionless transport like UDP. Even when VegaFS is used over TCP, multiple users on a multi-user client may share the same connection. Connection-based security cannot authenticate multiple users sharing the same connection. The same limitation applies to IP-based security. NFS runs on top of the RPC protocol, and it is possible to secure NFS by securing the RPC layer. In NFS security flavors, AUTH_SYS are notorious for its lack of secure user authentication. RPCSEC_GSS security flavor provides functions that allow data to be protected for integrity or encrypted for privacy. Meanwhile it introduces the overhead of context creation, context destruction, initial session keys, etc. Other security flavors such as AUTH_DH and AUTH_KERB4 are difficult to implement and require the administration of a security infrastructure on the network. VegaFS implements RPC-based security based on public key encryption and digital signature. We firstly generate the digest information according to the content of the RPC packet, and then encrypt it with private key (VC gets it from CRUL) of the user. That is, the signature of the user. We append this signature at the end of an RPC packet. A 1024-bit private key can generate a signature of fixed length 128 bytes. In this way, we need not to modify the RPC protocol. Digital signature can also ensure that the content of an RPC packet is not been changed or corrupts during
Proceedings of the IEEE International Conference on Cluster Computing (CLUSTER’03) 0-7695-2066-9/03 $17.00 © 2003 IEEE
transmission. No one can forge a signature unless he possesses the requester's private key, by which it is impossible to forge an RPC packet. In this way, a user can establish a secure channel with VS. In addition, we can also ensure privacy of message by means of encrypting the whole content of an RPC packet. We did not deploy this mechanism in VegaFS for the reason of performance.
4.3. Peer-to-peer Authorizations in VegaFS Peer-to-peer authorization is an important feature of VegaFS to support dynamic access control functions. In VegaFS, we develop a set of tools to help file owners issuing authorization certificates. Based on PKI technologies, a file owner can delegate his authority to other users with certain restrictions. In VegaFS, a certificate issued by a trusted CA identifies a user. Each certificate has an issuer and a subject. Certificates can be divided into two categories: identity certificates and authorization certificates. The identity certificate will bind a public key to a user. The authorization certificate, on the other hand, can make a more specific statement. For example, it can state that the subject entity is authorized to have access to a specified service. Furthermore, the authorization certificate does not necessarily need to carry any explicit, human understandable information about the identity of the subject. That is, the subject does not need to have a name. The subject can prove its title to the certificate by proving that it possesses the private key corresponding to the certified public key; that is the only way a subject can be trusted to be the legitimate owner of the certificate. In VegaFS, we use authorization certificate to implement the authorization between a file owner and a file sharer. Currently, the prototype of VegaFS adopts Simple Public Key Infrastructure (SPKI) [8] as its authorization certificate infrastructure. In the SPKI world, principals are keys. Delegations are made to a key, not to a key holder or a global name. Thus, an SPKI certificate identifies the specific key to which it grants authority. The certificate itself does not need to be as tightly controlled. In this way, every user can be a CA and can issue authorization certificate to other users who want access his files. In VegaFS, the information about file access right is stored in an authorization certificate issued by a file owner to a file sharer. When receiving a file-sharing request, the VegaFS server will check the authorization certificate issued by the file owner. According to the access right stored in this authorization certificate, the VegaFS server will do relevant access control tasks.
5. Evaluations Applying NFS to wide-area network have many problems, such as NFS is UDP-based, and does not
support the mechanisms such as flow-control, errorresume, and cooperative cache. However, NFS has some advantages. The history of NFS proves its stability, NFS client-side and server-side can be deployed in all platforms. Its source code can be downloaded anywhere, development is relatively easy. In fact, many file systems designed for wide area network are based on NFS, such as LegionFS, PVFS, CFS, SFS etc. In the development of VegaFS prototype, we did not put energy on the improvement of inherent limitations of NFS. Instead, we mainly use NFS as an experiment platform to verify the cross-domain ability of VegaFS. The methods adopted in VegaFS can easily migrate to other systems. Moreover, we also take the performance of VegaFS into account. The result of this chapter proves that the overhead introduced by our methods is in an acceptable extent. In order to show the above overhead provides limited impact on the performance of VegaFS, we use the same environment to test the performance of VegaFS, NFSv3 [21] and encrypted file system CFS-1.4.1 [4]. VegaFS, NFSv3, and CFS all communicate with clients through the RPC interfaces, and the mechanisms of remote file system mounting and cache are same. The difference among these file systems is that CFS adopts a user-level NFS server and uses DES encryption technology, NFS does not encrypt the data at all. In our experiment, we regard the performance of NFS as a reference mark. We use two Intel Pentium III machines at 667MHz, 128MB of RAM and 7.5 GB Seagate IDE disk to establish our test environment. The two machines were connected to a stand-alone dedicated switched 100 Mbps network. On both machines, we installed Redhat 7 and Linux-2.4.19 kernel. The test includes two parts: comparison of read/write large files and comparison of read/write files in different size. Before the experiments, we analyze that VegaFS will introduces a fixed amount of overhead for each file system RPC call. This fixed overhead is a function of RPC signature creating, signature verification and user key loading, whose time costs will not change when the file size changes. The test results showed in next section verify our analysis. When reading/writing large files, the performance of VegaFS is equal to that of NFS approximately. When reading/writing small files, only under a small threshold value (such as 20KB or 50KB) is the performance lost remarkable. Overall, the performance of VegaFS is acceptable.
5.1. Read/Write Large Files To compare the performance of read/write large files, we use Bonnie benchmark [5] to evaluate the overall performance of VegaFS. Our first test is to read/write a very large file (512MB). In VegaFS, file users can select signing and verifying the signature of RPC request or not, and we will test them respectively. The tested file systems
Proceedings of the IEEE International Conference on Cluster Computing (CLUSTER’03) 0-7695-2066-9/03 $17.00 © 2003 IEEE
include CFS-1.4.1, NFSv3, signing and verifying the signature VegaFS (VegaFS-SV), no signing and verifying the signature VegaFS (VegaFS-NSV). The content of test includes Sequential Output Char (SOC), Sequential Output Block (SOB), Sequential Output Rewrite (SOR), Sequential Input Char (SIC), and Sequential Input Block (SIB). Figure 4 shows the test results.
for read operation, when file size is less than 50KB, the performance is impacted remarkably; for write operation, when file size less than 20KB, the performance is impacted remarkably. When the file size increases, the performance of VegaFS-SV will approach the performance of NFSv3.
VegaFS-NSV
VegaFS-SV 10000
100
1000 (ms)
80
100
1MB
500KB
200KB
100KB
50KB
20KB
5KB
20
2KB
1
40
10KB
10
60
1KB
Throughput (100 KB/sec) .
NFSv3
VegaFS-SV
NFSv3
CFS
CFS
0 SOC SOB SOR
SIC
SIB
Figure 5. Comparison of writing files in different size Figure 4. Comparison of read/write of a large file CFS
NFSv3
VegaFS-SV
The VegaFS obtains the cross-domain ability and better security at a cost of a small performance lost. Compared with the NFS implementation, VegaFS introduces a fixed amount of overhead for each file system RPC call. In practice, if VegaFS is deployed in a wide area, the performance lost can be small compared to the actual time cost of data transferring over Internet.
5.2. Read/Write Files in Different Size
6. Conclusions and Future Work
The first test does not fully prove our arguments. So, we use our test program to read/write files in different size. Figure 5 presents the performance of write operation, and Figure 6 shows the performance of read operation. The tested file systems include CFS-1.4.1, NFSv3, and VegaFS-SV. The file size changes from 1KB to 1MB. From Figure 5 and Figure 6 we can see that, in CFS, the overhead of encrypting and decrypting increases when the test file size increases. The overhead is mainly introduced by encrypting and decrypting the file content and filenames when reading or writing files. In VegaFS,
In this paper, we introduce a prototype of grid file system that enables users access files independent of the constraints imposed by administrative domains. The main contribution of this paper can be summarized as crossdomain capability, dynamic and fine-grained access control ability, scalability, security and acceptable performance. Our test shows that the performance of VegaFS is better than CFS and acceptable compared with NFS. Especially, when transferring large files in VegaFS, the impact on performance is not significant.
50 0K B
10 0K B
20 K B
5K B
10000 1000 100 10 1 0.1
1K B
(ms)
From the results showed in Figure 4, we can educe that the performance of VegaFS is superior to that of CFS. One reason is that CFS will encrypt and decrypt file’s content and filename. Furthermore, CFS is implemented at user-level, which introduced the additional overhead of context switching. VegaFS-NSV has the similar performance with NFSv3. The overhead introduced by VegaFS-SV is not very remarkable. However, it doe not prove that the overhead introduced by signing and verifying is acceptable. In VegaFS, signing the RPC request happens in client side and verifying the request happens in server side. The response data from a VegaFS server to a VegaFS client does not have any protection, because in our prototype we resume the VegaFS server is trustable. In other words, the return data from VegaFS server has no signature and needs not be verified at VegaFS clients. However, from test results we can educe that compared with the cost of read/write operations, signing and verifying impacts the performance slightly.
Figure 6. Comparison of read files in different size
Proceedings of the IEEE International Conference on Cluster Computing (CLUSTER’03) 0-7695-2066-9/03 $17.00 © 2003 IEEE
The key idea of our design is to implant the user’s global unique identity (the public key) in file resource itself, which makes the file resource global unique as well. In next step, we will fulfill the unfinished work in the implementation of VegaFS, such as multiple namespaces, performance tuning, and bug fix. We also will use GSI [10] standard to replace the current SPKI standard, so that VegaFS can become a part of the OGSA [11] framework.
References [1] A. Adya, W. J. Bolosky, et al, “FARSITE: Federated, Available, and Reliable Storage for an Incompletely Trusted Environment”, Proceedings of the 5th OSDI, December 2002. [2] A. D. Alexandrov, M.Ibel, K.E. Schauser, and C.J.Scheiman, “Extending the operating system at the user level: the ufo global file system”, In 1997 Annual Technical Conference On Unix and Advanced Computing Systems (USENIX’ 97), January 1997. [3] E. Belani, A. Vahdat, T. Anderson, and M. Dahlin, ”The CRISIS Wide Area Security Architecture”, In Proceedings of the USENIX Security Symposium, San Antonio, Texas, January 1998. [4] M. Blaze, “A Cryptographic File System for Unix”, Proceedings of the First ACM Conference on Computer and Communications Security, November 1993. [5] Bonnie Filesystem Performance Benchmark. http://www.textuality.com/bonnie/. [6] V. Cate, “Alex-a Global File-system”, In Proceedings of the 1992 USENIX File System Workshop, May 1992, pp. 1-12. [7] W. Diffie, M.E.Hellman, “New Directions in Cryptography”, IEEE Transactions on Information Theory IT-22, November 1976. [8] C. M. Ellison, Bill Frantz, et al, “Simple public key certificate”, Internet draft draft-ietf-spki-cert-structure5.txt (expired), March 1998. [9] R. J. Figueiredo, N.H.Kapadia, and J.A.B.Fortes, “The PUNCH virtual file system: Seamless access to decentralized storage services in a computational grid”, In Proceedings of the Tenth IEEE International Symposium on High Performance Distributed Computing, IEEE Computer Society Press, August 2001.
[10] I. Foster, C. Kesselman, G. Tsudik, S. Tuecke, “A Security Architecture for Computational Grids”, Proc. 5th ACM Conference on Computer and Communications Security Conference, 1998, pp. 83-92. [11] I. Foster, C. Kesselman, J. Nick, S. Tuecke, “Grid Services for Distributed System Integration”, Computer, 2002, 35(6): pp. 37-46. [12] I. Foster, C. Kesselman, and S. Tuecke, “The Anatomy of the Grid: Enabling Scalable Virtual Organizations”, International Journal of High Performance Computing Applications, 2001, 15(3): pp. 200-222. [13] A. Freier, P. Karlton, and P. Kocher, Secure Socket Layer, Netscape, March 1996. [14] Gnutella, http://gnutelladev.wego.com. [15] A. S. Grimshaw, W.A.Wulf, et al. “The legion vision of a worldwide virtual computer”, Communications of the ACM, January 1997. [16] J. H. Howard, Michael L. Kazar, Sherri G. Menees, David A. Nichols, Robert N. Sidebotham M. Satyanarayanan, and Michael J. West, “Scale and performance in a distributed file system”, ACM Transactions on Computer Systems, February 1988, 6(1): pp. 51-81. [17] John Kubiatowicz, David Bindel, et al, “OceanStore: An Architecture for Global-Scale Persistent Storage”, Proceedings of the Ninth international Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2000), November 2000. [18] U. Maurer, “Modeling a public-key infrastructure”, Proceedings 1996 European Symposium on Research in Computer Security (ESORICS' 96), Lecture Notes in Computer, Science, Springer, LNCS, 1996, pp. 325-350. [19] D. Mazieres, M.Kaminsky, M.F.Kaashoek, and E.Witchel, “Separating key management from file system security”, In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP), Kiawah Island, South Carolina, 1999. [20] Napster, http://www.napster.com. [21] B. Pawlowski, C.Juszczak, P.Staubach, C.Smith, D.Lebel, and D.Hitz, “NFS version 3 design and implementation”, In Proceedings of the USENIX Summer Technical Conference, 1994.
Proceedings of the IEEE International Conference on Cluster Computing (CLUSTER’03) 0-7695-2066-9/03 $17.00 © 2003 IEEE
