Capability File Names over HTTP

Fahad Owais

Master of Science Thesis Stockholm, Sweden, July 25 2010

TRITA-ICT-EX-2010:230

Capability File Names over HTTP

Fahad Owais

July 25, 2010

Technical University of DenmarkInformatics and Mathematical ModellingBuilding 321, DK-2800 Kongens Lyngby, DenmarkPhone +45 45253351, Fax +45 45882673reception@imm.dtu.dkwww.imm.dtu.dk

1

Abstract

File access over the Internet adds a whole new dimension to the continuouslyevolving World Wide Web. Considering its signi�cance in the big picture, thereexists a need to provide a completely secure and �exible way to share and ac-cess content existing on a �le host web server somewhere over the Internet. Anumber of access control mechanisms attempt to do this with moderate suc-cess with most of them lacking the ability to allow sharing of information tounauthenticated users and adequate �le-based access control capabilities.

Capability File Names provide a new and completely unique access control mech-anism that uses �le names as a means to store access control information against�les on a remote location and allows a user unhindered access to his �les alongwith the capability to delegate rights as deemed necessary.

The aim of this thesis project has been to develop a prototype implementationthat makes use of Capability File Names as a way to control access to �les andfolders placed on an HTTP Web Server over the Internet. It involves a Linuximplementation on the client-side using �FUSE� (Filesystem in Userspace) witha server-side implementation using Java Server Pages (JSP). The access controlfeatures have entirely been implemented on server side with the client user onlyneeding the Capability File Names pointing to the original �les on the server togain access to them. In addition to the server and client applications, there isa separate utility provided to the user hosting the server allowing generation ofCapability File Names against �les located on the server.

2

Sammanfattning

Tillgång till �ler via Internet ger en helt ny dimension till ständigt förändrasWorld Wide Web. Med tanke på dess betydelse i den stora bilden �nns det ettbehov av ett helt säkert och �exibelt sätt att dela och få åtkomst till innehåll som�nns på en �l värd webbserver någonstans på Internet. Ett antal mekanismerför åtkomstkontroll försök att göra detta med måttlig framgång med de �estaav dem saknar förmågan att tillåta utbyte av information till icke-autentiseradeanvändare och adekvat �lbaserade tillgång kapacitet kontroll.

Capability �lnamn ge en ny och helt unik tillgång kontrollmekanism som an-vänder �lnamn som ett sätt att lagra information passagekontroll mot �ler påen avlägsen plats och gör en användare fritt tillträde till sina �ler tillsammansmed möjlighet att delegera rättigheter som anses nödvändiga.

Syftet med detta examensarbete har varit att utveckla en prototyp genom-förande som använder sig av Capability �lnamn som ett sätt att kontrolleratillträdet till �ler och mappar placeras på en HTTP-webbservern via Inter-net. Det handlar om en Linux genomförandet på klientsidan med "FUSE"(�lesystem i användarrumsbibliotek) med en server-side genomförandet medJava Server Pages (JSP). Passersystemet funktioner har helt genomförts påserver med kunden användaren bara behöver Capability �lnamn pekar på deursprungliga �lerna på servern för att få tillgång till dem. Utöver de server-ochklient, �nns ett separat verktyg som tillhandahålls användaren värd för serverntillåter generationen av förmåga �lnamn mot �ler på servern.

3

Acknowledgments

It is a pleasure to thank those who made this thesis possible. First and foremost,I would like to show my gratitude to my supervisor, Christian Damsgaard Jensenwhose guidance and support at every step of the way enabled me to successfullycomplete the task at hand and develop a clear understanding of the subject. Iwould also like to acknowledge my external supervisor from the Royal Instituteof Technology (KTH), Markus Hidell whose support and encouragement duringthe project was instrumental to its accomplishment.

I would also like to thank my family and friends who were always there for mein the toughest of times. And �nally, I would like to o�er my regards to all ofthose who supported and helped me in any respect during the project.

Fahad Owais

4

Contents

1 Introduction 10

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4 Scope Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 File Systems 14

2.1 UNIX Processes and File I/O . . . . . . . . . . . . . . . . . . . . 14

2.2 File Representation . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 The File structure . . . . . . . . . . . . . . . . . . . . . . 16

2.3 System Calls and Library Functions . . . . . . . . . . . . . . . . 17

2.4 Basic File Operations . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.1 Open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.2 Creat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.3 Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.4 Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.5 Close . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.6 Lseek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5 File Locking at Application Level . . . . . . . . . . . . . . . . . . 20

2.5.1 �ock() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5.2 lockf() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5.3 fcntl() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.6 Data and Attribute Caching . . . . . . . . . . . . . . . . . . . . . 21

2.7 Path Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . 22

2.8 File Types and Permissions . . . . . . . . . . . . . . . . . . . . . 23

2.8.1 Permissions in Directories . . . . . . . . . . . . . . . . . . 24

2.8.2 Access Control Lists (ACLs) . . . . . . . . . . . . . . . . 25

2.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5

3 Virtual File Systems 27

3.1 Virtual File System (VFS) � The Vnode Layer . . . . . . . . . . 27

3.2 Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Installable File System (IFS) . . . . . . . . . . . . . . . . . . . . 29

3.4 Filesystem in Userspace (FUSE) . . . . . . . . . . . . . . . . . . 30

3.4.1 Fuse Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4.1.1 Standard Interface . . . . . . . . . . . . . . . . . 31

3.4.1.2 Low-level Interface . . . . . . . . . . . . . . . . . 32

3.4.2 Fuse Operations . . . . . . . . . . . . . . . . . . . . . . . 32

3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Distributed File Systems 34

4.1 Network File System (NFS) . . . . . . . . . . . . . . . . . . . . . 34

4.2 Andrew File System (AFS) . . . . . . . . . . . . . . . . . . . . . 35

4.3 Server Message Block (SMB) - Common Internet File System(CIFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4 Secure File System (SFS) . . . . . . . . . . . . . . . . . . . . . . 37

4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Capability File System 39

5.1 Capability File Names . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.2 Basic Structure . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.3 Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1.4 Usage and Delegation . . . . . . . . . . . . . . . . . . . . 40

5.1.5 With Server Authentication . . . . . . . . . . . . . . . . . 41

5.1.6 With Client Authentication . . . . . . . . . . . . . . . . . 41

5.2 Capability File System (CapaFS) . . . . . . . . . . . . . . . . . . 42

5.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2.2 The Client Virtual File System . . . . . . . . . . . . . . . 42

5.2.3 The File Server . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6

6 Capability File Names in a Distributed File System 44

6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2 Capability Name Generation . . . . . . . . . . . . . . . . . . . . 44

6.2.1 Method and Parameters . . . . . . . . . . . . . . . . . . . 45

6.2.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2.4 The Use Case . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.3 Capability Name Representation in the File System . . . . . . . 47

6.4 Capability File System Operations . . . . . . . . . . . . . . . . . 48

6.4.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4.2 Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4.3 Open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.4.4 Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.4.5 Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.4.6 Seek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.5 Capability File Server . . . . . . . . . . . . . . . . . . . . . . . . 50

6.5.1 Parsing and Decrypting the Capability File Name . . . . 50

6.5.2 File Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.5.2.1 Use Case . . . . . . . . . . . . . . . . . . . . . . 51

6.5.3 File Update . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.5.3.1 Use Case . . . . . . . . . . . . . . . . . . . . . . 54

6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7 Design and Implementation 57

7.1 Top-level Architecture . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2 The Communication Protocol . . . . . . . . . . . . . . . . . . . . 58

7.2.1 Capability File Name Generation . . . . . . . . . . . . . . 58

7.2.2 Capability File System - File Retrieval/Update . . . . . . 59

7.3 Applied Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.3.1 FUSE over C . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.3.2 Java Server Pages (JSP) . . . . . . . . . . . . . . . . . . . 60

7.3.3 Java Key Store . . . . . . . . . . . . . . . . . . . . . . . . 61

7.3.4 Web Server � Apache Tomcat/ Glass�sh . . . . . . . . . . 61

7.4 The Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7

7.4.1 Capability File Name Encryption and Encoding . . . . . . 61

7.4.1.1 CapaEncrypter . . . . . . . . . . . . . . . . . . . 62

7.4.1.2 UnicodeFormatter . . . . . . . . . . . . . . . . . 63

7.4.2 Capability File Name Generation . . . . . . . . . . . . . . 63

7.4.2.1 Server Authentication . . . . . . . . . . . . . . . 64

7.4.2.2 Change Password Utility . . . . . . . . . . . . . 64

7.4.3 File Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.4.4 File Update . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.5 The Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.5.1 File Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.5.2 FUSE File Operations . . . . . . . . . . . . . . . . . . . . 68

7.5.2.1 Lookup . . . . . . . . . . . . . . . . . . . . . . . 68

7.5.2.2 Getattr . . . . . . . . . . . . . . . . . . . . . . . 68

7.5.2.3 Readdir . . . . . . . . . . . . . . . . . . . . . . . 69

7.5.2.4 Open . . . . . . . . . . . . . . . . . . . . . . . . 69

7.5.2.5 Read . . . . . . . . . . . . . . . . . . . . . . . . 70

7.5.2.6 Write . . . . . . . . . . . . . . . . . . . . . . . . 70

7.5.2.7 Setattr . . . . . . . . . . . . . . . . . . . . . . . 71

7.5.2.8 Destroy . . . . . . . . . . . . . . . . . . . . . . . 71

7.5.3 File Update . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.5.4 Client Cache . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.5.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8 Evaluation 74

8.1 Functionality Evaluation . . . . . . . . . . . . . . . . . . . . . . . 74

8.1.1 Capability File Name Generator . . . . . . . . . . . . . . 74

8.1.1.1 Login Utility . . . . . . . . . . . . . . . . . . . . 74

8.1.1.2 Capability File Name Generator . . . . . . . . . 75

8.1.1.3 Change Password Utility . . . . . . . . . . . . . 75

8.1.2 CapaFS Client Application . . . . . . . . . . . . . . . . . 76

8.2 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.2.1 Server Part Encryption . . . . . . . . . . . . . . . . . . . 78

8.2.2 Communication over SSL . . . . . . . . . . . . . . . . . . 78

8

8.2.3 Con�dentiality . . . . . . . . . . . . . . . . . . . . . . . . 78

8.2.4 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.2.5 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.2.6 Authenticity . . . . . . . . . . . . . . . . . . . . . . . . . 80

8.3 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . 80

8.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

9 Conclusions and Future Work 82

9.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

9.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

9.2.1 SSL based Client application . . . . . . . . . . . . . . . . 83

9.2.2 Performance Tuning . . . . . . . . . . . . . . . . . . . . . 83

A Installation 85

A.1 Installing the Server Applications . . . . . . . . . . . . . . . . . . 85

A.2 Setting up SSL for Capability File Name Generation . . . . . . . 85

A.3 Setting up FUSE and the CapaFS Client Application . . . . . . . 86

B Code Listings 87

B.1 FUSE Low-Level Interface Operations . . . . . . . . . . . . . . . 87

9

Chapter 1

Introduction

1.1 Background

The Internet has proven to be one of the greatest inventions of today's age andhas become very much a necessity in our everyday lives. But it was not meant tobe utilized in the way that it is being today when the concept of networking was�rst introduced during the cold war after the Soviet Union's launch of the �rstarti�cial satellite called Sputnik, in 1957. It was during this cold war that theUnited States established the Advanced Research Projects Agency (ARPA) thatplayed a key role in Internet's development. The idea of packets and packet-switching networks triggered its development in 1962 during the Project RANDresearch study and involved terminals connected through a central mainframecomputer. Leonard Kleinrock from MIT wrote a paper on packet-switching in1961[1]. It was J.C.R. Licklider though, in 1962, who thought of networking ina more broader through his use of the words �Galactic Network� in a conceptwhich involved computers interconnected globally allowing access to data andservices.[2]

In 1967, the introduction of ARPANET was one of the major developmentstowards the internet we know and cherish[3]. Switches were developed andhosted and �nally led to the �rst networking protocol, Network Control Protocol(NCP). The network, starting o� with only four computers in the beginning to20 users in 1968, now has millions of users connected to it. The �rst Emailapplication was created in 1972 leading to the concept of mailing lists soonafterwards which was one of the �rst indications of the modern one-to-manycommunication architecture when networks had essentially been up till then ameans to provide one-to-one communication.

The introduction of TCP/IP in 1973 set the tone for what was to follow. Bymid-1980s, all hosts over the ARPANET were made to follow the TCP/IP stan-dards which made the communication independent of the physical medium be-ing used. It also provided the ability to connect networks of hosts with othersimilar networks. The idea was then being referred to as �internets�. Laterthe National Science Foundation (NSF) introduced CSNET for civilians, later

10

named NSFNET and received extensive usage with increasing number of col-leges and universities opting to use it to link themselves with each other inthe early 1990s. Restrictions on commercial use were there till 1995 when theywere lifted after which NSF stepped back allowing commercial providers to takeresulting in further expansion of the Internet.

As time has passed, the internet itself has seen major developments. It startedo� as a simple network being used to communicate a small number of hostsand soon developed into a network of networks with servers and clients com-municating with each other in a 1-to-many communication architecture. Nowit supports concepts such as peer-to-peer computing, distributed systems, Web2.0, and social networks making it more of a global platform where every usercontributes in one way or the other. File and resource sharing as well was seensomething that could only work in small networks. But with the introductionof the World-Wide-Web protocols like HTTP, FTP and SSH, it makes perfectsense to merge together the possibilities presented by them with the capabilitiesprovided by network �le systems such as Network File System (NFS), AndrewFile System (AFS) or Common Internet File System (CIFS). This is exactlywhat this project aims to do. By merging the two together along with adequatesecurity features, this project aims to provide a platform for �le sharing thatutilizes the showcased potential of the World-Wide-Web.

1.2 Problem

Although a number of network �le systems provide a way to share resourceswith other users, all of them rely heavily on a central authority of some sort formanagement of authorization privileges to authenticated and unauthenticatedusers. Another thing missing from most of the distributed �le systems is theability to de�ne access control information against individual users and a setof �les. Capability File Names is a new and innovative access control mecha-nism through which it is possible to have all authorization related informationencoded inside the �le name thus separating the authentication and authoriza-tion activities from the �le system. Additionally, this mechanism also allowsinformation to be shared with unauthenticated users.

Distributed �le systems providing �le sharing capabilities and numerous otherfeatures have always had the problem of passing through �rewalls as one ofthe biggest hurdles when it comes to covering Wide Area Networks. Firewallsdeployed over networks are usually con�gured to allow tra�c meant for onlya handful of well-known services. So it is considerably di�cult to go through�rewalls over multiple networks. With that in mind, HTTP which is undoubt-edly the most well-known application layer service, could well be considered auniversally acceptable means to communicate as nearly every network �rewallallows HTTP tra�c to go through them. This is exactly what this project aimsat accomplishing by providing �le sharing capabilities through HTTP.

Additionally, reliance on third-party storage solutions (services such as Dropboxcome to mind) was also one of the major concerns when the requirements for thisproject were laid out. Entrusting a third party with con�dential information isnot something many organizations or individuals are willing to do. So another

11

important goal of this project has been to develop a solution that allows suchcapabilities without the involvement of any third parties.

Here is a brief list of problems that this project aims to address,

• Reliance on third parties.

• Need for a single shared location.

• Inadequate access control features against individual users and �les.

• Control over authentication and authorization activities

• Complexity involved in rights delegation.

• Inadequate coverage over Wide Area Networks and the inability to getthrough network �rewalls.

1.3 Purpose

The aim of this project has been to provide a solution to the problems de�nedearlier. The software architecture has been built such that all of the problemsmentioned in the previous section are taken care of. The basic architectureinvolves an HTTP based web server hosting a web application developed using aserver-side scripting language such as PHP or JSP along with a client applicationrunning as a Virtual File System over UNIX. The architecture is primarily basedon the following principles taking into account all problems that need to beaddressed,

• Provide an implementation based on the client-server architecture withthe server acting as a host to �les to be shared and the client providingaccess to them.

• The client and server would be communicating over HTTP so the serverwould need to host a web application and would play the role of a webserver.

• The client application runs as a virtual �le system on top of the UNIX�le system and would support basic �le operations such as read and writethat would be carried out on the remote �le.

• The server and client would implement an access control mechanism usingthe concept of Capability File Names.

• The capability �le names would provide a way to store access controlinformation against individual �les.

• The server would have the ability to encrypt and decrypt access relatedinformation against �les on the server using a symmetric key or a public-private key pair.

• The capability �le name will serve as the authentication device thus pro-viding an uncomplicated way to share and delegate information.

12

• The server would be run by the user and would only require setting up ofa web server thus ensuring that no third-party is involved.

1.4 Scope Limitations

Taking into account the fact that this project is meant to produce only a pro-totype of the �nal product, there are certain limitations to the functionalitiesthat have been provided:

• The prototype does not allow any sort of folder management on the clientside that would re�ect on the server. The folder structure maintained onclient-side will only impact the client �le system.

• Capability �le names are not persistent by themselves. They can be madepersistent though using Symbolic links which need to point to the capa-bility �le name provided through the generation procedure.

• It is not possible to create or delete a �le on the server through the clientapplication.

• It is not possible to copy and replace entire �les bearing the same namethrough the client application.

• Large �les may result in slight delays on slower networks.

• The client application does not use Secure Socket Layer (SSL) to sendHTTP requests which means that an attacker can easily intercept themessages and extract the capability �le name resulting in that �le gettingexposed to the attacker.

• It is assumed that the distribution of capability �le names will take placeover a safe and secure channel through methods available to the partiescommunicating.

• The prototype implementation does not support �le locking.

• The �le content update activity is based on the last-update principle mean-ing that the changes made on a newer version of a �le would be lost ifchanges made on an older version take place afterwards.

13

Chapter 2

File Systems

2.1 UNIX Processes and File I/O

The hardware protection mechanisms employed in UNIX prohibit access to theaddress space of a process and the di�erent data structures inside the kernel.So a UNIX process may read or write only to its own address space.

Process execution takes place in either the user mode or the kernel mode. Whilein user mode, the process operates on its own stack and is able to executeinstructions from the application binary or any linked libraries. The processcan shift to the kernel mode if it needs to make a system call. This can be doneby issuing a special hardware instruction, the mechanics of which are speci�cto the hardware architecture in which the activity is being carried out. Whilein the kernel mode, the process execution takes place in a separate kernel stackand results in all the system call arguments getting duplicated inside the kerneladdress space.

Process related information is stored in the form of two di�erent kernel struc-tures; namely, the �proc� structure and the �user� structure. The proc structureis always present in the system memory even when the corresponding processis not running. On the other hand, the user structure contains informationrequired only when the process is in execution. The user structure also incor-porates a number of �elds that contain information related to �le access whichthe proc structure does not have. A few of the more important �elds in the userstructure are de�ned below:[9]

u_cdir - The inode of the current working directory is stored here. This isused during pathname resolution when a user speci�es a relative pathname.

u_uid/u_gid - The process user ID and group ID used for permissions check-ing for �le-access-based system calls. Similarly, u_euid and u_egid hold thee�ective user and group IDs.

u_o�le - This array contains the process �le descriptors.

u_arg - An array of system call arguments set up during the transition fromuser to kernel mode when invoking a system call.

14

u_base - This �eld holds the address of a user space bu�er in which to readdata from or write data to when processing a system call such as read() orwrite().

u_count - The number of bytes to read or write is held here. It is decrementedduring the I/O operation and the result can be passed back to the user.

u_o�set - This �eld records the o�set within the �le for the current read orwrite operation.

u_error - When processing a system call, this �eld is set if an error is encoun-tered. The value of u_error is then passed back to the user when the systemcall returns.

2.2 File Representation

In the original Unix �lesystem, the �rst block of 512 bytes known as the bootblock does not get used and is left empty. The second block called the su-perblock, contains information about the �lesystem as a whole such as the num-ber of blocks in the �lesystem, the number of inodes (�les), and the number offree inodes and data blocks. Each �le is represented on disk by an inode. Theinode is retrieved from the disk whenever a �le gets opened. Operations suchas the stat() system call retrieve much of the information they require from theinode structure. The inode must remain in memory for the duration of the openand is typically written back to disk if any operations require changes to theinode structure.

Unix makes use of an inode cache which retains inodes even after �les have beenclosed and the inode is no longer required. This is done to avoid the need toread inodes from disk every time a �le is opened. This is particularly useful forinodes representing �le paths that are accessed more frequently such as /, /usr,and /home.

The original Unix speci�cation for an inode is comprised of the following set of�elds,[9]

i_mode - This �eld speci�es whether the �le is a directory (IFDIR), a blockspecial �le (IFBLK), or a character special �le (IFCHR). The IFREG �ag, whichwas introduced later represents a regular �le whereas in the original speci�ca-tion, a regular �le is indicated by setting none of the three �ags de�ned above.

i_nlink - This �eld de�nes the number of hard links to the �le. When this �eldreaches zero, the inode is freed.

i_uid - The �le's user ID.

i_gid - The �le's group ID.

i_size - The �le size in bytes.

i_addr - This �eld holds block addresses on disk where the �le's data blocks areheld. It is represented as an array of 8 pointers. Each pointer could reference asingle disk block, giving 512 bytes of storage or could reference what is called anindirect block. Each indirect block contained 32 pointers, each of which could

15

point to a 512 byte block of storage or a double indirect block. Double indirectspoint to indirect data blocks.

i_mtime - The time the �le was last modi�ed.

i_atime - The time the �le was last accessed.

Figure 2.1: Unix File Structure[11]

2.2.1 The File structure

The �le structure contains information about how the �le was opened and wherethe current �le pointer is positioned within the �le for reading or writing. The�u_o�le[]� array in the user structure is indexed by the �le descriptor numberto locate a pointer to a �le structure. File descriptors particular to a �le arereturned from system calls such as open().The �rst �le that is opened by a userprocess is assigned a �le descriptor value of 3. When the new process is created,it typically inherits the �rst three �le descriptors from its parent. These �ledescriptors (0, 1, and 2) have a special meaning to routines in the C runtimelibrary and refer to the standard input, standard output, and standard error ofthe process respectively.

16

The original speci�cation of the �le structure contained the following members:[9]

f_�ag - This �ag was set based on how the �le was opened. If open for readingit was set to FREAD, and if open for writing it was set to FWRITE.

f_count - Each �le structure had a reference count. This �eld is further de-scribed below.

f_inode - After a �le is opened, the inode is read in from disk and stored inan in-core inode structure. This �eld points to the in-core inode.

f_o�set - This �eld records the o�set within the �le when reading or writing.Initially it will be zero and will be incremented by each subsequent read or writeor modi�ed by lseek().

2.3 System Calls and Library Functions

System calls are functions that transfer control from the user process to theoperating system kernel. Functions such as read() and write() are system calls.The process invokes them with the appropriate arguments, control transfers tothe kernel where the system call is executed, results are passed back to thecalling process, and �nally, control is passed back to the user process. Libraryfunctions typically provide a richer set of features. For example, the fread()library function reads a number of elements of data of speci�ed size from a�le. While presenting this formatted data to the user, internally it will call theread() system call to actually read data from the �le. Library functions areimplemented on top of system calls. Applications wishing to have much morecontrol over how they perform I/O in order to optimize for performance may wellinvoke system calls directly. System calls can consume more time than invokinglibrary functions because they involve transferring control of the process fromuser mode to kernel mode.

Arguments passed to system calls are placed on the user stack prior to invokinga hardware instruction that then transfers the calling process from user mode tokernel mode. Once inside the kernel, any system call handler needs to be ableto access the arguments, because the process may sleep awaiting some resource,resulting in a context switch, the kernel needs to copy these arguments into thekernel address space.

The sysent[] array speci�es all of the system calls available, including the numberof arguments. By executing a hardware trap instruction, control is passed fromuser space to the kernel and the kernel trap() function runs to determine thesystem call to be processed. The C library function linked with the user programstores a unique value on the user stack corresponding to the system call. Thekernel uses this value to locate the entry in sysent[] to understand how manyarguments are being passed.

2.4 Basic File Operations

This section covers the six basic �le operations in UNIX; namely, open, creat,read, write, close, lseek. In addition to de�ning the operations, this section also

17

focuses on how these system calls get handled by the kernel and what internalkernel functions are responsible for carrying out the speci�c tasks.

2.4.1 Open

int open(const char *path, int o�ag, /* mode_t mode */...)

This function allows a user to open a �le for reading or writing purposes. Itaccepts as arguments the �le path (path) and an integer value that can be madeup of multiple �ags in order to specify the mode in which the user wants to openthe �le (o�ag). There are three basic modes available for this purpose,

• O_RDONLY � Opens the �le in read-only mode

• O_WRONLY � Opens the �le in write-only mode

• O_RDWR � Opens the �le both read and write mode

There are a few other �ags as well that one can use in combination with theprimary �ags through a bitwise-OR operation. Some of these are O_CREAT,O_APPEND, O_SYNC, O_TRUNC, etc. If the �le to be opened does notexist, it is created based on the permission �ags speci�ed as one of the arguments(mode) in the system call. In response, the function returns a �le descriptorthat represents the inode for the �le in question.

In the kernel, the open() system call gets handled by the kernel function open()whose �rst task is to resolve the pathname passed to the original function callwhich it does using the function namei(). Another function open1() is calledonce the inode is accessible which essentially does all the work. It is responsiblefor ensuring that the calling user has access to the �le. This is done using a callto the function access(). A �le table entry is allocated next using the functionfalloc() which returns a �le descriptor that points to the newly created �le tableentry. The �le table entry and the inode are linked together before the functionreturns.

2.4.2 Creat

int creat(const char *path, mode_t mode)

The creat() system call performs the same function as open() with the parameter�mode� speci�ed. It creates a new �le if the name speci�ed through �path� doesnot exist otherwise it just truncates the already existing �le.

If the �le does not previously exist, the kernel uses the function ialloc() to assigna free inode from the �le system. Additionally, a new directory entry gets createdcontaining the speci�ed �le name and the newly created inode identi�er. If the�le existed before the creat() call, the �le is truncated using a call to the functionfree() that frees up all blocks that were being used up by the �le. In additionto this, the newly created inode is written to the disk using bwrite(). Finally, a�le table entry is created in addition to an allocation in the �le descriptor table.The �le descriptor is returned as the response.

18

2.4.3 Read

int read(int d, char *buf, int nbytes)

The read function takes in as arguments the �le descriptor returned from theopen() system call, the number of bytes to be read, and the output bu�er pointerwhich is to be �lled up with contents from the �le. The bytes are read from the�le's current o�set which is `0' when the �le is read the �rst time. This o�setgets incremented by the number of bytes read every time a read() operation isperformed.

The kernel function that handles the read() system call is rdwr() which in turncalls readi(). Readi() uses the function bmap() to get the physical block addressin return for the logical address in the form of the �le o�set that is passed ontothe function. The returned block address is passed onto the function bread()which reads the data contained in the block. Finally the function uiomove()is called, which goes on to �lling up the bu�er speci�ed in the read() systemcall with the data returned by bread(). This procedure is carried out at everyiteration by the readi() function and data is read block by block with the baseo�set value getting incremented until the required number of bytes have beenread.

2.4.4 Write

int write(int d, char *buf, int nbytes)

The write function takes in as arguments the �le descriptor returned from theopen() system call, the number of bytes to be written, and the input bu�erpointer from which the speci�ed number of bytes are to be written to the�le. The bytes are written from the �le's current o�set which is `0' when the�le is written the �rst time. This o�set gets incremented by the number ofbytes written every time a write() operation is performed. Additionally, if theO_APPEND option is set when the �le is opened, the current o�set is set tothe end of the �le which results in the bytes getting written from that point on.

The kernel function that handles the write() system call is rdwr() which inturn calls writei(). Writei() uses the function bmap() to get the physical blockaddress in return for the logical address in the form of the �le o�set that ispassed onto the function. However, if the block against this �le o�set does notexist, a new block gets allocated by the kernel using the alloc() function. Thefunction then, similar to the readi() function, writes a block or a part of it usingbwrite() in every iteration and continues until all of the data has been written.

2.4.5 Close

int close (int fd)

The close() takes the �le descriptor of an open �le as an argument and closesthe �le it represents.

The kernel function close() is used to handle this system call which takes actionson the �le table and inode table entries based on their reference counts. If the

19

reference count for the �le table entry is equal to 1, the kernel frees up the �letable entry and releases the inode using iput().

2.4.6 Lseek

o�_t lseek (int fd, o�_t o�set, int reference)

The lseek() provides the ability to change the current o�set for an open �le.It takes as arguments, the �le descriptor, the byte o�set and a reference valuewhich determines the point where the o�set will be applied from. This referencepoint can either be the beginning of the �le or the current o�set based on theprevious read() or write() system calls or it can be the end of the �le. The valuereturned in response represents the �le o�set from which the next read or writeoperation will be carried out.

The kernel in this case only updates the o�set value stored in the �le tableagainst the entry corresponding to the �le in question.

2.5 File Locking at Application Level

Locks issued on �les at application level can either be for the whole �le or forspeci�c sections of a �le. Sections of a �le are also called records, hence �leand record locking. There are two types of locks that can be used to coordinateaccess to �les, namely mandatory and advisory locks. With advisory lockingalso called record locking, it is possible for cooperating processes to safely accessa �le in a controlled manner.

There are three functions which can be used for advisory locking. These arelockf(), �ock(), and fcntl(). Because record locking as de�ned by fcntl() issupported by all appropriate UNIX standards, this is the routine that shouldbe ideally used for application portability.

2.5.1 �ock()

The �ock() function has the signature,

i n t f l o c k ( fd , opera t i on )

�ock() is used to set an advisory lock on the whole �le. The lock type is de�nedthrough the �operation� argument and can be either exclusive (LOCK_EX)or shared (LOCK_SH). The lock can be removed by using the LOCK_UNoperation.

2.5.2 lockf()

The lockf() function has the signature,

i n t l o c k f ( i n t f i l d e s , i n t funct ion , o f f_t s i z e )

20

It can be used to obtain advisory locks on �le segments. �size� de�nes thenumber of bytes to be locked starting from the �le pointer location which canbe manipulate using the lseek() operation.

The �function� argument can be any one of the following values,

F_LOCK - Sets an exclusive lock on the �le and blocks execution of the callingprocess until previous lock is released.

F_TLOCK - Sets an exclusive lock on the �le and does not block executionof the calling process if the �le is already locked.

F_ULOCK - Unlocks the �le segment

F_TEST - Checks whether a lock already exists on a certain �le segment.

2.5.3 fcntl()

The fcntl() system call has the following signature,

i n t f c n t l ( i n t f i l d e s , i n t cmd , . . . )

The ��ock� structure is passed as the third argument in the fcntl() system calland determines what type of lock is acquired. It contains the following set ofattributes,

s t r u c t f l o c k {shor t l_type ; /∗ F_RDLCK, F_WRLCK or F_UNLOCK ∗/shor t l_whence ; /∗ f l a g f o r s t a r t i n g o f f s e t ∗/of f_t l_s ta r t ; /∗ r e l a t i v e o f f s e t in bytes ∗/of f_t l_len ; /∗ s i z e ; i f 0 then un t i l EOF ∗/pid_t l_pid ; /∗ proce s s ID o f l ock ho lder ∗/} ;

The command to be executed de�ned by the �cmd� argument operates on the��ock� structure. Three types of commands can be executed using the fcntl()system call,

F_GETLK - Retrieves the �rst lock represented by the information providedthrough the �ock structure.

F_SETLK - Sets a new lock or clears an existing lock based on the value of�l_type�.

F_SETLKW - Same as F_SETLK except that it blocks the calling processif a lock already exists on the �le segment.

2.6 Data and Attribute Caching

There are three options, supported under the Single UNIX Speci�cation, thatcan be passed to open() that have an impact on subsequent I/O operations. Thethree options that are supported from a standards perspective are: O_SYNC,O_DSYNC, O_RSYNC. [9]

21

O_SYNC - For all types of writes, whether allocation is required or not, thedata and any meta-data updates are committed to disk before the write returns.

O_DSYNC - When a write occurs, the data will be committed to disk beforethe write returns but the �le's meta-data may not be written to disk at thisstage.

O_RSYNC - If both the O_RSYNC and O_DSYNC �ags are set, the readreturns after the data has been read and the �le attributes have been updatedon disk, with the exception of �le timestamps that may be written later. If thereare any writes pending that cover the range of data to be read, these writes arecommitted before the read returns. If both the O_RSYNC and O_SYNC �agsare set, the behavior is identical to that of setting O_RSYNC and O_DSYNCexcept that all �le attributes changed by the read operation (including all timeattributes) must also be committed to disk before the read returns.

2.7 Path Name Resolution

Consider a standard open() system call that has a �le pathname speci�ed as oneof the arguments. In order to be able to execute the system call this pathnameneeds to be resolved �rst. For example, consider,

�ledescriptor = open("/etc/�le1", O_RDONLY),

which attempts to open ��le1� as a read-only �le contained in the directory�/etc� while returning a �le descriptor in response. In order to ensure that�/etc� is in fact a directory and that ��le1� is a �le inside the same directory,the �rst thing that the kernel needs to identify is whether the pathname providedis absolute or relative. A pathname starting with a slash `/' is considered anabsolute path and points to the root directory. On the other hand, a pathnamewithout a slash in the beginning is considered relative although the di�erentdirectories in the pathname are still separated by slashes in between.

The search for the inode corresponding to the pathname speci�ed is carried outdi�erently depending on whether the path is absolute or relative. In case ofan absolute pathname, the kernel looks up �rootdir� that points to the rootinode inside the root �lesystem. During the kernel bootstrap, this value getsinitialized and stays that way until the kernel is active. In case of a relativepathname, �u_cdir� is the point where search starts from. �u_cdir� is a part ofthe user kernel structure inside a process and is essentially an inode representingthe current working directory which gets updated every time there is a changeof directory.

The kernel function or routine that carries out this activity is called namei() andmakes use of the di�erent �elds available in the user structure. The functionthen looks for a non-�nal component in the directory that matches the pathdescription and continues to do so until there is only the �nal component leftwhich can be either a �le or a directory or even a symbolic link. The �nalcomponent in the case presented above is the �le ��le1�. Before reading aninode from the disk, the kernel tries to locate it in the inode cache. This isachieved through a function called �iget()� which also results in the inode's

22

hold count (i_count) getting incremented. The �iput()� function releases theinode and decrements �i_count�. �i_count� is used to determine the numberof instances that are active for an inode. Once it reaches 0, the inode can beclassi�ed as free and can be placed on the free list.[9, 7]

2.8 File Types and Permissions

Each �le and folder in Unix stores information about its type and permissionsin the form of octets. There are �ve octets in all that are used to represent the�le type and permissions. The �rst octet de�nes the �le type with each octalvalue representing one of the �le types. The following table presents the list ofpossible values,

Octal Value Binary Value Character Meaning

0 000 - Plain File1 001 d Directory2 010 c Character Device3 011 b Block Device4 100 l Symbolic Link5 101 s Socket6 110 = or p FIFO

Table 2.1: File Type Octets

The next three octets de�ne �le permissions with each octet representing adi�erent role or user class in the system. The three user classes are,

• Owner � the user that owns the �le; requires the UID of the process to bethe same as the �le's user

• Group � the group that the �le belongs to; requires the GID of the processto be a member of the �le's group

• Other � Everyone else; not belonging to either the Owner or the Groupclass

Three types of permissions can be de�ned for each class of users,

• Read � Allows access to the �le's contents

• Write � Allows a �le to be modi�ed

• Execute � Allows a �le to be executed

The three bits constituting an octet each represent a permission type. Thefollowing table further elaborates the possibilities,

23

Octal digit Text equivalent Binary value Meaning

0 � 000 All types of access are denied1 �x 001 Execute access is allowed only2 -w- 010 Write access is allowed only3 -wx 011 Write and execute access are allowed4 r� 100 Read access is allowed only5 r-x 101 Read and execute access are allowed6 rw- 110 Read and write access are allowed7 rwx 111 Everything is allowed

Table 2.2: Permission Octets

The �nal three bits in the �ve octet stream represent SUID, SGID and thesticky bit. SUID and SGID allow certain more privileged tasks to be carriedout by normal users. When a �le having the SUID bit set is executed theprocess executing the �le will have the same access rights as that of the owner.Similarly if the SGID bit is on, the process will get executed with privileges thatthe �le group has been granted. While SUID has no e�ect on non-executable�les, the SGID bit with execute bits disabled can be used to enable some formof �le or record locking. Finally, the sticky bit was used to keep programs inmemory to speed up execution of that program on subsequent attempts and isnow considered obsolete.

2.8.1 Permissions in Directories

The permission set is de�ned in the exact same manner in case of directoriessince essentially they are represented as �les in the Unix �lesystem. The per-missions do represent a slightly di�erent meaning though when it comes todirectories. The read, write and execute permissions represent the followingprivileges,

• Read � Allows access to names of �les in a directory; does not provideaccess to the �les' inodes

• Write � Allows contents of a directory to be modi�ed through creation,deletion and renaming of �les.

• Execute � Provides access to the contained �les' inodes and allows a switchto the respective directory using the chdir() system call.

�Execute� permission is required in combination with �Read� and �Write� to beable to carry out certain tasks. For instance, both �Execute� and �Write� bitsshould be enabled in order to be able to create, rename or delete �les inside adirectory. This also means that a user can rename or delete �les in a directorywith �Write� and �Execute� permissions even if it does not have access to the �lesthemselves. Additionally, without the �Execute� ability, a user cannot access�les in a directory even if the user owns them or has all permissions against the�les assigned to it.

24

The SUID bit has no e�ect on directories. However, setting the SGID bit for adirectory causes the newly created �les to inherit the identity of the directorygroup instead of inheriting that of the user initiating the procedure. Setting thesticky bit in case of directories ensures that only the owner of the contained �leor directory or the root user is able to delete it. This feature is not supportedby all Unix implementations.

2.8.2 Access Control Lists (ACLs)

Access Control Lists (ACLs) were not a part of the original UNIX distribution.They were introduced much later on in Linux, OpenBSD, Solaris, etc, and arebased primarily on the POSIX and NFSv4 ACL standards. ACLs provide amuch greater level of control to the user in comparison to user groups that havebeen a part of every UNIX distribution to date. This section will focus on theACL functionality provided in Linux based on the POSIX.1e standard.

ACLs in general, provide the ability to assign access rights against �les, direc-tories, processes or any other object in the �le system to individual users inaddition to groups. Two utilities that come as a part of this ACL implementa-tion are `getfacl' and `setfacl'.

`getfacl' is used to simply view an object's ACL properties, so running `getfacl�le1' would return the following output,

# g e t f a c l f i l e 1#f i l e : f i l e 1#owner :1234#group :1234user : : rwxgroup : : rw−other : : r−−

`setfacl', on the other hand, is �ttingly used to set an object's ACL properties.The two most important operations you can carry out using this utility are themodi�cation and removal of an ACL entry which can be done using the `-m'and `-x' options respectively. A typical ACL entry modi�cation command wouldlook like,

# s e t f a c l −m u : fahad : rwx , group : l i nux : rw−, o : : r−− f i l e 1

A number of other options are also provided with the `setfacl' utility such as `-R'that allows an operation to be carried out recursively to �les and directories,and a few others that allow greater control over how ACLs are created.

2.9 Summary

This chapter provided an overview of the basic �le system concepts mainlycatering to the UNIX �le system. The basic �le structure in the form of inodeswas introduced and explained brie�y. Other structures used to carry out thedi�erent �le operations were presented in addition to a brief overview of the

25

six basic �le operations; open, creat, read, write, close and lseek. File lockingwas introduced and the chapter took a look at how it is handled by the UNIX�le system. Data and attribute caching was touched upon slightly while asection was dedicated to how UNIX resolves path names. Finally, �le types andpermissions in UNIX were described brie�y with some focus on permissions fordirectories and access control lists.

26

Chapter 3

Virtual File Systems

A Virtual File System provides an interface between a �le system and the kernel.It acts as an abstraction layer on top of a �le system and provides the abilityto de�ne customized operations running transparently on top of the �le system.The virtual �le system layer on appearance is just like a regular �le system andprovides the ability to build a �le system on top of the actual �le system. Soessentially, there could be any type of �le system, be it a network �le systemor a Windows �le system running on top of the UNIX �le system and the userwould not feel a di�erence. There have been several implementations of virtual�le system for di�erent operating systems. Some of them are brie�y describedin the following sections,

3.1 Virtual File System (VFS) � The Vnode Layer

The Vnode layer architecture was proposed by Sun Microsystems in 1986 for theUNIX kernel. It was introduced to provide a way to incorporate multiple �lesystems within the UNIX kernel. In addition to providing remote �le systemsto be implemented, it also allows other �le systems that are not supportedby the UNIX platform to be made accessible. The layer takes control at thetime execution of system calls on �les. It is then responsible for redirecting therequests to the appropriate function handlers implemented on top of the UNIXkernel implementation.

The Virtual File System introduced by Sun is based on the idea of Vnodes.Vnode is a �le structure similar to inode that represents an element in thevirtual �le system with the ability to store information related to �les placedremotely, in an unrecognized format, devices or even processes as suggested byFigure 3.1. The �le system types supported by the kernel are stored in the `vfs'structure with respective operations to be executed in response to system callsrepresented through the `vnode' structure.

27

Figure 3.1: Virtual File System[33]

3.2 Portals

Portals were introduced with 4.4BSD and work in a similar way to the VirtualFile System for Linux presented in the previous section. They provide a wayfor the �le system to open unknown �le types and devices in the same way thatit would a regular �le.

Figure 3.2: Portal File System[21]

This feature is made available through the use of the portal daemon running inthe BSD operating system. As shown in the �gure, the mount point �p� is aportal having any requests pointed to it being handled by the portal daemon.The kernel would not have anything to do with what follows the portal directorysince it refers the portal �le system. So the string �/tcp/foo.com/smtp� wouldinstead be passed on to the portal daemon which would extract information

28

from it and in this case, create a TCP connection against �foo.com� and returna socket descriptor back to the user.[21]

The portals can be utilized in a similar way to provide many other types ofservices and any information being transferred between the kernel and the portal�le system is transparent to the user. So, the user would not feel the di�erencebetween accessing a �le from the portal �le system and accessing it from thelocal �le system.

3.3 Installable File System (IFS)

Installable File System was co-developed by IBM and Microsoft for OS/2 andwas introduced with OS/2 Version 1.2. It provides the ability to add new �lesystems to the kernel without the need to modify it. Microsoft introduced asimilar mechanism with Windows NT after the OS/2 collaboration betweenIBM and Microsoft came to an end.

OS/2, similar to other operating systems, provides an Application ProgrammingInterface (API) that is a set of kernel-level routines through which certain op-erations can be carried out on �les in the �le system. The open, read, write andclose operations are carried out through the DosOpen, DosRead, DosWrite andDosClose API calls. IFS provides a way for the �le system being implementedto de�ne its own responses against the function calls.

Each IFS must de�ne a �le system driver which implements the �le systemsemantics and which runs in the kernel of the operating system. In OS/2,the kernel is referred to as `ring 0' while `ring3' refers to the user space whereapplication programs are executed. The OS/2 �le system router, as shown inthe �gure, acts as a bridge between the API and the �le system driver. Itis responsible for routing requests to the appropriate �le system based on themount directory.[24]The �le systems being represented by IFS can exist locallyor at a remote location, as illustrated by the �gure.

29

Figure 3.3: Installable File System[24]

3.4 Filesystem in Userspace (FUSE)

Filesystem in Userspace (FUSE) provides the ability to develop �le systems inthe form of a kernel module that runs in user space and does so without the needto modify the kernel. FUSE acts a bridge between the user implementation andthe kernel interfaces and thus o�ers its users the opportunity to write Virtual�le systems.

Although some information related to �le systems would be useful, a user candevelop a userspace �le system using FUSE with minimal or no information inrelation to �le system internals and kernel programming. The �gure presentedbelow better illustrates the idea behind FUSE,

30

Figure 3.4: Filesystem in Userspace[30]

As the �gure illustrates, the FUSE module is responsible for handling requestsfrom VFS when a system call gets executed on the mounted directory actingas the virtual �le system. The control is then transferred onto the user spacewhere the user implementation takes over the glibc functionality and carries outcustom tasks. The result of that is forwarded back to VFS which then pushesthe result onwards as a response to the original system call.

3.4.1 Fuse Interfaces

FUSE provides two di�erent interfaces against which users can de�ne �le sys-tems. There are certain characteristics that di�erentiate the two and certainpros and cons that need to be weighed in according to the requirements of the�le system being implemented. FUSE also provides a multithreaded interfaceallowing up to 150 requests to be handled at the same as demonstrated byZFS [thread: �zfs-fuse 0.4.0 beta1 released�. Google groups: ZFS-FUSE]. Thestandard and low-level interfaces are presented brie�y in the following sections.

3.4.1.1 Standard Interface

The FUSE standard interface is based on �le path names. The interface pro-vides operations very similar in structure to the glibc system calls and makes itsigni�cantly easier for the user to implement the required operations. The �lenode the operation is referring to is identi�ed by the complete �le path name.

31

The interface provided has most of the necessary features required for imple-menting �le systems of any kind but can result in lesser e�ciency in comparisonto the low-level interface which operates a lot closer to the kernel thus providingbetter performance.

3.4.1.2 Low-level Interface

The low-level interface provided by FUSE di�ers a great deal from the standardinterface. The operations resemble the kernel module interface more than theglibc system calls. It provides considerable improvements in performance whichis helped by the fact that it is based on �le inode numbers instead of �le pathnames as was the case with the standard interface. It also requires the user tomanually handle the operation tra�c �ow between the kernel and the interface.

3.4.2 Fuse Operations

A structure de�ned in the FUSE library contains signatures of all the operationssupported by FUSE. The list presented contains de�nitions of operations in thestandard interface. The low-level interface, as mentioned earlier, makes useof slightly more complex structures and mechanisms designed to provide morecontrol to the user.

s t r u c t fuse_operat ions {i n t (∗ g e t a t t r ) ( const char ∗ , s t r u c t s t a t ∗ ) ;i n t (∗ r e ad l i nk ) ( const char ∗ , char ∗ , s i z e_t ) ;i n t (∗ g e t d i r ) ( const char ∗ , fuse_dirh_t , f u s e_d i r f i l_ t ) ;i n t (∗mknod) ( const char ∗ , mode_t , dev_t ) ;i n t (∗mkdir ) ( const char ∗ , mode_t ) ;i n t (∗ unl ink ) ( const char ∗ ) ;i n t (∗ rmdir ) ( const char ∗ ) ;i n t (∗ symlink ) ( const char ∗ , const char ∗ ) ;i n t (∗ rename ) ( const char ∗ , const char ∗ ) ;i n t (∗ l i n k ) ( const char ∗ , const char ∗ ) ;i n t (∗chmod) ( const char ∗ , mode_t ) ;i n t (∗ chown) ( const char ∗ , uid_t , gid_t ) ;i n t (∗ t runcate ) ( const char ∗ , o f f_t ) ;i n t (∗ utime ) ( const char ∗ , s t r u c t utimbuf ∗ ) ;i n t (∗ open ) ( const char ∗ , s t r u c t f u s e_ f i l e_ in f o ∗ ) ;i n t (∗ read ) ( const char ∗ , char ∗ , s ize_t , of f_t ,

s t r u c t f u s e_ f i l e_ in f o ∗ ) ;i n t (∗ wr i t e ) ( const char ∗ , const char ∗ , s ize_t ,

of f_t , s t r u c t f u s e_ f i l e_ in f o ∗ ) ;i n t (∗ s t a t f s ) ( const char ∗ , s t r u c t s t a t f s ∗ ) ;i n t (∗ f l u s h ) ( const char ∗ , s t r u c t f u s e_ f i l e_ in f o ∗ ) ;i n t (∗ r e l e a s e ) ( const char ∗ , s t r u c t f u s e_ f i l e_ in f o ∗ ) ;i n t (∗ f sync ) ( const char ∗ , int , s t r u c t f u s e_ f i l e_ in f o ∗ ) ;i n t (∗ s e t x a t t r ) ( const char ∗ , const char ∗ ,

const char ∗ , s ize_t , i n t ) ;i n t (∗ ge txa t t r ) ( const char ∗ , const char ∗ , char ∗ , s i z e_t ) ;

32

i n t (∗ l i s t x a t t r ) ( const char ∗ , char ∗ , s i z e_t ) ;i n t (∗ removexattr ) ( const char ∗ , const char ∗ ) ;} ;

Each of the operations supported by FUSE represents a system call supportedby glibc but in this case it would be the user code that forms the proceedingswhen the call is made. Not all of these functions need to be implementedfor the �le system to work properly. On the other hand, functions such asopen, read, readdir and getattr (similar to stat()) can be considered essentialfor implementing even the simplest of �le systems. The function signatures usedfor the FUSE low-level interface are presented in Appendix B.1.

3.5 Summary

This chapter focused on the concept of Virtual File Systems. After a briefoverview of the idea behind Virtual File Systems, some of the more commonlyused Virtual File System implementations are looked upon including the VnodeLayer for UNIX, Portals for BSD and the Installable File System for Windows.A detailed overview of File System in Userspace (FUSE) was provided in theend which is one of the major components of the prototype implementation forthis project.

33

Chapter 4

Distributed File Systems

4.1 Network File System (NFS)

The Network File System (NFS), introduced by Sun Microsystems in 1985,proved to be one of the most successful and widely used remote �le systems.Although a few other notable remote �le systems had made their way to UNIX,NFS was unprecedented in the way that it was machine and system independentwhich it manages to accomplish through the use of an External Data Represen-tation (XDR) speci�cation for describing protocols. (Sandberg, 1985)

The Network File System is based upon the Remote Procedure Call (RPC)mechanism which provides a way to de�ne, organize, implement and maintainremote services. RPC calls behave similarly to local procedure in that they aresynchronous and block execution until a response is received. Additionally, NFSmakes use of a stateless protocol, meaning that it doesn't store state informationin relation to client session and the requests made by the client. Additionally,NFS runs over User Datagram Protocol (UDP) independent of the applicationlayer protocol. Newer versions of NFS have added support for asynchronouswrites while a new stateful protocol is introduced in NFS v4. The introductionof Transmission Control Protocol (TCP) as the transport protocol in NFS v3was also a welcome addition to the NFS repertoire as it put to rest any previousreliability concerns in relation to the use of NFS over wide-area networks.

34

Figure 4.1: The Network File System[16]

NFS provides all of the essential features expected from a local UNIX �le systemand includes all of the basic �le operations such as open, close, read, write, etc.NFS provides a UNIX-like authentication mechanism with �le access based onuser and group identi�ers which means that the server and client user identi�ersneed to be coordinated and there must exist a �at identi�er space over the wholenetwork for this to work. There are a number of security risks in the way thatNFS authenticates its users. NFS relies completely on the client authenticatingthe user making it vulnerable if the client machine gets compromised. Addi-tionally, client's information is stored on the server in the form of IP addresseswhich could also be misused through IP address forgery. Finally, NFS allowsa user to access a �le through its �le handle as long as it is valid and doesn'tauthenticate the client on every access attempt which makes it vulnerable incase a �le handle is forged by an attacker.

4.2 Andrew File System (AFS)

Andrew File System, developed in the mid-to-late 1980s by IBM and CarnegieMellon University, has been one of the most widely used distributed �le sys-tems and along with NFS, is considered to have based the foundation for manymodern commercial distributed �le systems. It is considered a far superior dis-tributed �le system in comparison with its peers and provides better scalability,performance and security.

AFS was originally designed for UNIX based systems but gradually added sup-port for other operating systems such as Windows and MacOS. AFS, like anyother distributed �le system, gives the impression to the user as if the remote�les being accessed are stored locally. AFS is based on the concepts of cells

35

which represent a portion of �le space and which combine together to form acomplete �le system.

AFS is renowned for being one of the most scalable distributed �le systemsin commercial use. This scalability comes from the local caching mechanismemployed in an AFS which attempts to store locally as much data as possibleresulting in lesser network tra�c and minimal use of network's resources. In ad-dition, the AFS architecture provides the ability to replicate servers through theuse of a Volume Location Database (VLDB) which stores information regardingthe physical location of �le contents. In addition to minimizing network band-width usage, this feature also improves scalability in the way that if one servermalfunctions and stops working the rest can take over thus ensuring availability.

AFS also provides certain security features that allow its users to utilize its otherfeatures even in insecure networks. It provides an authentication mechanismbased on Kerberos and provides support for Access Control Lists which ensuresthat only authenticated users are allowed access to resources while also makingsure that they are able to execute only the operations that they are authorizedfor.

One of the reasons that organizations are hesitant in going for AFS is the in-creased complexity that it accompanies in comparison to other distributed �lesystems. Setting up and administering an AFS server requires a considerableamount of expertise and know-how in relation to the many features packagedwithin. As a result of this and the fact that it is still a fairly expensive solutionprice-wise, only academic institutions and other larger organizations such asNASA, CERN and some US military bodies hold a major share of organizationsthat decide to adopt AFS as their distributed �le system of choice. Anotherreason for its low market share is the domination of Microsoft through its Com-mon Internet File System (CIFS) which also provides a lot of features and ispresented next.

4.3 Server Message Block (SMB) - Common In-ternet File System (CIFS)

The Server Message Block (SMB) �le sharing protocol was introduced by IBMand was later modi�ed extensively by Microsoft while using it as the foundationon which all the �le and printer sharing capabilities have been based on in theWindows Platform. SMB was originally meant to work on top of NetBIOSand did so when it was included as part of the �le sharing capabilities in DiskOperating System (DOS).

Major developments made their way through Windows NT which allowed RPC-based remote calls and introduced the concept of �domains� to which a useris assigned by the Primary Domain Controller (PDC). Domains added to theidea of �workgroups� which were introduced with earlier SMB versions used inWindows 9x and Windows for Workgoups. While in workgroups security isdistributed and decentralized, in case of domains it is controlled by a centralauthority called the Primary Domain Controller (PDC) with many Backup Do-

36

main Controllers (BDC). Also, while a client can be assigned to more than oneworkgroups, in case of domains it can be assigned to only one.

Figure 4.2: File Sharing using the SMB Protocol[34]

The SMB protocol version designed to run over TCP was introduced with Win-dows 2000 a few years after it was renamed as the Common Internet File System(CIFS). Latter versions have used this TCP based architecture and expandedupon it with the latest SMB v2.0 getting introduced with Windows Vista. Aversion of SMB called �Samba� was developed for UNIX systems to provide �leand printer sharing capabilities to Windows clients while also allowing integra-tion with Windows domains.

In essence, SMB provides �le and printer sharing capabilities along with someadded features such as an opportunistic �le locking mechanism and InterprocessCommunication (IPC) that have made it one of the most widely used network�le systems.

4.4 Secure File System (SFS)

Secure File System (SFS) is based on the idea of self-certifying pathnames pre-sented by a group of computer scientists from MIT. Self-certifying pathnamesprovide the ability to separate key management from �le system security. Indoing so, it avoids the need for having any centralized control and providesa single namespace across all domains worldwide.It makes use of public keycryptography to authenticate users.

37

The self-certifying pathnames are used to represent �les in the global names-pace. It is composed of the server host name or IP addres and the Host IDwhich is the cryptographic hash of the server's public key and its location. Thepublic key of the server allows the client to verify the server's authenticity. Theauthentication of client involves a trusted third-party. The client upon �rst usehas to authenticate itslef through an authentication agent which communicateswith the server and authenticates the client while a �le is being accessed.

The self-certifying pathnames do not contain any authorization information andare used for authentication purposes only. The authorization mechanism in SFSis based on the standard UNIX user and group IDs which means that for anyunauthorized user to get access to an SFS based server, an administrator withsystem privilges would need to get involved. The concept of Capability FileNames used for this project is di�erent in the sense that it includes authorizationinformation against �les in the �le names allowing even unauthorized usersaccess to selected number of �les without the involvement of an administrator.

4.5 Summary

This chapter focused on some of the well-known distributed network �le systemsthat have been in use over the years. Network File System is probably one of themost well-known distributed �le systems and is introduced in the �rst sectionwith some details on what goes on behind the scenes. Andrew File System andthe Common Internet File System are described next with chapter coming to anend with a brief overview of a slightly lesser-known �le system known as SecureFile System which is very relevant to the project and the concept of CapabilityFile Names.

38

Chapter 5

Capability File System

5.1 Capability File Names

5.1.1 Overview

A Capability File Name provides a way to store �le authorization informationinside the �le name. Furthermore it acts as an authentication device throughpossession of the capability �le name which proves the authenticity of the clientrequesting the �le.

5.1.2 Basic Structure

A capability �le name is structured as follows,

The basic capability �le name structure can be divided into the client andserver part. The client part is composed of the information that a client wouldneed to identify the server while the server part represents encoded informationcontaining the full �le path on the server and the access rights based on whichthat �le will be opened for the requesting client.

The client part of a capability �le name contains a pre�x �/capafs/� which wouldbe consistent for every capability �le name created against a �le. It is followedby the host name or IP address of the server on which the �le resides and theport number on which the server is listening for client requests. Since HTTP isthe protocol being used to communicate in this project, this �eld represents theport number on which the web server would be running.

The server part is encrypted using either a fast symmetric key that only theserver needs to be aware of, or the server's public key that is part of public-private key pair used against every client. The public-private key method isuseful only if either client or server authentication is employed both of which will

39

be presented later. The symmetric key works perfectly if the basic capability �lename structure is followed. The server used this key to encrypt the complete �lepath on the server along with the read-write-execute triplet used to determinethe actions a client can carry out on the �le. They are represented in thestandard UNIX way using the `r', `w' and `x' symbols to represent the read,write and execute operations. The execute operation would only be of any useif in future implementations folder manipulation on the server �le system is alsoincluded. So for executable or non-executable �les, the execute attribute doesnot have any signi�cance whatsoever.

5.1.3 Creation

The capability �le name creation takes place on the server that hosts the �le andis done using a separate utility that takes in as parameters the server host nameand port number, the complete �le path pointing to its location on the server,and the access permission set to be used to determine the kind of operationsthat can be carried out on the �le.

The server host name and port number would be needed in order for the clientto be able to determine who to contact and communicate with for the �le thecapability name is being created for. The �le path and access permissions areencrypted using a key maintained on the server. Using a symmetric cipher isthe more plausible option if only the server needs to be aware of the key andwould also require less maintenance. In order to introduce server authentica-tion though, there would be the need to maintain a public-private key pair asdescribed in one of the following sections.

In order to be able to create the capability �le name, the client needs to authen-ticate itself to the server which could be something as simple as a username-password based login mechanism over a secure channel or could potentially bebased on something similar to the client authentication method presented laterwhich can also to be used authenticate the client when the server is presentedwith a capability name for �le access.

5.1.4 Usage and Delegation

The capability �le name created through the server �le creation utility providesaccess to a �le on the server on which the capability name was created. Inorder to use the name to access the respective �le, a client interface would beneeded that takes in as input the capability �le name and fetches the �le inquestion. Furthermore it would allow operations such as read, seek and write tobe carried out on that �le. In Section 4.2, such a client application is presentedthat provides the above mentioned features.

A capability �le name itself serves as an authentication device and possessionof the �le name is in essence all one needs to authenticate oneself against theserver. So once a capability �le name has been created, it can be used by theentity that created the capability name as well as anyone else who gets to bein possession of the capability name. So any user deemed trustworthy by thecapability creator can be provided access to a �le resource through conveyance

40

of the capability �le name to that user. The method used to make this transferis not part of the discussion but it is of utmost importance that it is done ina safe and secure manner to avoid any leakage or misuse of information beingshared.

Finally, since capability �le names are just names so they are not persistent inany way so the user provided with the capability name must �nd a way to storeit. Any kind of storage mechanism can be used to ful�ll this purpose. It canbe as simple as storing the names in a text �le to storing it in a database tocreating a symbolic link which points to the capability �le.

5.1.5 With Server Authentication

The simple structure presented in the previous sections su�ers from the man-in-the-middle attack even if the communication is carried out over a secure channel.Someone intercepting messages from the client and server can just replay thewhole exchange of messages and act as a client to the server and as a server tothe client. A way to avoid this would be through authentication of the serverbased on which any further communication would take place.

The structure presented in the �gure above provides a way for the client toauthenticate the server. The server's public key `SPuk' is included in the ca-pability �le name while the server part is encrypted using that same key. Theclient can then use the server's public key to create a session key which it en-crypts using the server's public key at the beginning of communication. Theserver then responds with a message encoded using the session key thus provingthat server is in possession of its private key.

5.1.6 With Client Authentication

Using the original capability �le name structure, the client is authenticatedbased on the idea that it possesses the capability name. However, it cannot beused as an identity for the client. Getting hold of the client's identity informationcan be useful for monitoring purposes and can be used to determine how thecapabilities are propagated from one user to another.

A way to do this would be to include the client's public key in the server partof the capability �le name that is encrypted using the server public key asillustrated in �gure above. Following from the scheme presented in Section4.1.5, the client can then send capability �le name encrypted using the client'sprivate key to the server. The server would then just use the client's public keyto decrypt the message and extract the capability �le name thus authenticatingthe client.

41

Figure 5.1: Capability File System

5.2 Capability File System (CapaFS)

5.2.1 Overview

The Capability File System (CapaFS) is a �le system running on user-levelthat provides a platform for capability �le names. Through this �le system,it is possible to access remote �les placed on a �le server just like local �les.CapaFS is responsible for communication with the server over a secure channel,providing it with the capability �le name that was originally created from theserver, receive content from the server, and carry out operations such as read,write and seek on the �le located on the server.

There are two major components of the Capability File System; one is a virtual�le system running at user-level that initiates the request and serves as theclient, while the other is the �le server which receives requests from the clientand responds accordingly.

5.2.2 The Client Virtual File System

CapaFS client �le system provides a way to access remote �les locally. It runsas a process in the background and acts exactly like a local �le directory whenthe content existing in that directory is fetched from a remote resource. It doesso by creating a secure channel between itself and the �le server and carries outthe �le operations that the user requests it to on the remote �le.

As illustrated in Figure 5.1, it works as a shared library that intercepts �leoperation requests and allows custom activities to be carried out instead. Sowhenever a �le gets opened in CapaFS, instead of having `libc' handle the re-quest, it's CapaFSLIB that gets hold of it and passes the request onto the remoteserver setting the �le handle accordingly. Same would be the case for other op-erations like read, write or seek which would be carried out on the remote �leinstead.

The virtual �le system running on top of the UNIX �le system would have theability to interpret capability �le names and based on information obtained fromthe capability �le name, it would initiate requests to the remote server. The

42

client part composed of the server host name or IP address and the server portnumber running the server application would be used to establish a connectionwith the server. The client application would then attach the server part ofthe capability �le name along with every subsequent request made to the serverbased on whether the remote �le is being read or updated.

5.2.3 The File Server

The CapaFS �le server is the location where all of the user �les are stored. Theserver provides access to the �les on the server through an application runningon the server which accepts requests from the client containing the server partof the capability �le name and carries out the requested activity. The servershould be able to decode the information it has received from the client. Theserver has access to the symmetric key or the public-private key pair used toencrypt the server part of the capability �le name as a part of the capability�le name generation activity which also takes place at the server. The servershould also be able to analyze the access permissions assigned against a �le andretrieve and update content accordingly.

The server application service running in the user space would only have accessto �les and resources required for the operations thus prohibiting access tosystem and other users' �les. The service would be run under the initiatinguser's privileges so it would not pose any threat to the system or other users ifit is compromised.

5.3 Summary

This chapter provided a complete description of the Capability File Names andthe di�erent concepts that accompany it. Its basic structure, the creation pro-cedure, the authentication mechanisms for the client and server and how it isdelegated to other users, are all discussed in detail. Then the two major com-ponents of the Capability File System, the client and the server are discussed.

43

Chapter 6

Capability File Names in a

Distributed File System

6.1 Overview

Capability �le names provide a very convenient way to access �les placed on aremote location. But in order to utilize them there exists a need for a DistributedFile System to exist that can be accessed remotely. The idea behind this projectwas to have this distributed �le system placed on a web server that allows accessto it through the HTTP protocol.

The Capability File Server would then also host a web application that wouldallow this communication to take place. It would be responsible for extractingthe complete �le path and access rights from the encrypted part of the capability�le name meant for the server. Based on the information it has obtained, itwould then allow the di�erent �le operations to be carried out on the original�le on the server. Apart from this, the server would also host a web applicationor a simple desktop application meant to be run locally that would provide theuser the ability to create a capability �le name against a �le located on theserver.

The client, however, would need an application that takes over the local �lesystem and acts as a temporary storage spot for the �les stored on the webserver. This application would run on top of the UNIX �le system and wouldintercept any �le-related activities that take place within the con�nes of theCapability File System. The user would need to have this application runningin the background after which it would be able to access remote �les as if theywere stored locally.

6.2 Capability Name Generation

The generation of a capability �le name is one of the core processes required forthe Capability File System implementation. It is done using a separate utility

44

that exists on the server. It can be a web-based application that is hosted on theweb server and provides remote access or a simple desktop application that mayor may not provide remote access. In any case, an authentication mechanismis implemented on top of the generation utility that allows access to only theprivileged users. In case it is a remote application, the communication wouldtake place over a secure channel, like if it is a web application, the sessions wouldbe encrypted using SSL certi�cates thus ensuring con�dentiality and integrity.

6.2.1 Method and Parameters

The application takes in as parameters the server host name or IP address,the port number on which the server is listening for requests, the complete�le path on the server and the access permissions to be granted on the �le.In return, it produces a capability �le name containing all the parameters inform or the other. The capability �le name gets pre�xed by the string �capafs�followed by the server host name and the port number. The �rst three attributesconstitute the client part. The server part composed of the �le path and accesspermissions is encrypted using a symmetric key based on 3DES(Triple DataEncryption Standard) or AES(Advanced Encryption Standard). The encryptedpart is then appended to the client part to form the capability �le which isreturned back to the user. The server port number, the �le path and accessrights are provided by the user.

6.2.2 Encryption

The encryption key used is stored on the server and is protected from disclosure.A fast symmetric key algorithm is used for this purpose since only the serverwould ever need access to the key. The encrypted content is then formattedin Unicode and presented to the user along with the client part. The returnedcapability �le name can then be used through the client application for accessingthe �le remotely.

The symmetric key used here I created upon �rst use by the web applicationand is stored at a location that is accessible only by the application itself.Furthermore, the key should be encoded using a system or application widekey that is used to store keys and certi�cates for services such as SSL.

6.2.3 Authentication

The capability �le name generation procedure is preceded by a login mechanismthrough which access to only the privileged users is allowed. At the moment,only a single user termed as the 'Administrator' is allowed access to the service.The utility takes in a user name and password based on which either the useris forwarded to the generation utility or prompted with an error message. Thecommunication takes place over a secure and encrypted channel. The utilitywould also provide a 'Change Password' mechanism allowing the user to changethe password stored against the only administrator user.

45

6.2.4 The Use Case

Actors: User

Purpose: To generate capability �le names

Description: This use case allows the user to generate capability �le namesagainst �le located on the server

Pre-Conditions

• The web server must be up and running with the Capability File NameGeneration Web Application

• SSL certi�cate must have been created on the web server and sent to theuser

• User must be logged in

Typical Course of EventsActor Action System Response

1 User enters the Server Port Number,Capability File Name, selects

appropriate access right permissioncheck boxes and clicks the Generate

button2 System validates the entered

information.3 System checks whether the entered

�le exists on the server4 System retrieves the AES based

symmetric key stored locally5 System encrypts server part of the

capability �le name composed of the�le path and access permissionsgranted against the �le using theAES based symmetric key. Theaccess permission string has read,write and execute permissionsrepresented by 'r', 'w' and 'x'

respectively with '-' as the defaultpermission.

6 The encrypted server part is encodedin Unicode formatting

7 The capability �le name is createdby combining together the clientpart composed of the pre�x

'/capafs', the host IP address andport number, and the server part, all

separated by a '/'8 System responds back to the user

with the capability �le name.

46

Alternative Course

Step 3

- If any of the �elds entered is empty or invalid, the system returns an errormessage to the user accordingly.

Step 4

- If the �le does not exist or cannot be read, the system returns an error messageto the user.

- If the AES based symmetric key does not exist, the system creates one andstores it on the local �le system for subsequent usage.

Step 5

- If an exception occurs during the encryption activity, the system returns anerror message to the user.

Post-Conditions

The capability �le name has been generated and displayed back to the user.

6.3 Capability Name Representation in the FileSystem

The capability �le name obtained using the capability name generation utilitypresented in the previous section provides a way to access the �le it is gener-ated against. The name contains all the information one needs to retrieve the�le's contents and carry out certain �le operations. The client application doesexactly that. It extracts information from the capability �le name based onwhich it initiates communication with the server. The client part composed ofthe server host name and port number is meant for the client application thatsets up a connection with the server based on that information. The server partmeant for the server is sent in the form of an HTTP request when the �le isopened on client-side.

As mentioned earlier, the capability �le names are not persistent by defaultbut can be made so through the use of symbolic links. The client applicationwould upon execution, mount a directory on the client �le system. This direc-tory would act as a virtual �le system and would be accessible as long as theapplication is running. Any permitted operations on the �le will be handled bythe client application and executed on the remote �le system. The client appli-cation running on top of the UNIX �le system intercepts the `libc' system callsand provides a way to execute functionality required for the implementation ofcapability �le names.

The capability �le name can then be used to access the �le on the remote server.It can be read, updated and executed just like a local �le. The name is validonly if the client application is running. To further elaborate the idea, considera �le �foo.txt� located on the server against which the capability �le name hasbeen generated and would look something like the following text,

47

/ capa f s /130 .225 .71 .216/8080/ a7521571c62f4d224fdec

Now all the user needs to do is create a symbolic link against this text and runthe �le in whatever way it wants to. Now consider the symbolic link �bar� iscreated against the above text. Then it would be possible to access the �le inthe following ways,

# cat / capa f s /130 .225 .71 .216/8080/ a7521571c62f4d224fdec# ged i t / capa f s /130 .225 .71 .216/8080/ a7521571c62f4d224fdec# cat bar# ged i t bar

As the text shows, the �le located on a remote server would appear to be like alocal �le to the user with the symbolic links making it even more unnoticable.After opening the �le through the desired application, the user can carry outoperations on the �le just the way it would on a local �le and the desired e�ectsubsequently would be observable on the remote �le.

6.4 Capability File System Operations

The client application running on top of the UNIX �le system supports certainbasic �le operations that result in the information being obtained from theremote server where the �les are located.

6.4.1 Initialization

The application at the time of execution would be responsible for mounting thevirtual �le system on a local directory. The mounted directory would appear tohave no �les and folders within as it allows access to �le content only through thecapability �le name. The client application would also maintain a local cachesomewhere on the client �le system. The cache would be used as a temporarystorage for retreived �le content and would be updated if it is modi�ed on theserver by the client itself or by some other means.

6.4.2 Lookup

The application based on the capability �le name provided by the user wouldretrieve the �le content from the remote server upon the �rst �le lookup andstore it in a local cache maintained as a �le on the local �le system. The lookuptakes place whenever a �le system attempts to located a directory or �le basedon its name. When a user attempts to access a �le in the capability �le systemthe �rst time, the �le is not present in the local cache. As a result, the �leis then fetched from the server. If the �le does exist in the cache, a query ismade to the server during the open() operation presented later to determinewhether the �le in the cache is the one placed on the server. This is done bycomparing the modi�cation times of the two �les. Upon the �rst retrieval, alongwith the �le content, the server also provides the client application with the last

48

modi�cation time for the �le on the server. The data in the cache is updatedonly if it has been modi�ed on the server by the client itself or by some otheruser that has access to the �le. The maintenance of a local cache on the client�le system means that the �le would not be fetched from the server every timeit is accessed but from the local cache instead. Same goes for the seek operationwhich would just move the �le pointer to the speci�ed location on the localcache. On a write operation though, the remote �le would be updated alongwith the local cache. The server sends the last modi�ed time again to the clientin response to a write request. This avoids the need to synchronize clocks of theserver and client. Maintaining a local cache results in a signi�cant improvementin performance and also leads to lesser processing overhead.

The �le content from the remote server would be requested through an HTTPPOST request that is created based on the capability �le name the client appli-cation receives as part of the lookup operation. A TCP connection is establishedbetween the client application and server using the IP address and port numberobtained from the client part of the capability �le name. The client then sendsthe HTTP POST request containing the server part of the capability �le nameto the remote server. On success, it receives back the reply from the servercontaining the �le contents which are stored in the local cache.

After the �le has been retrieved from the server, the user can access the �lethrough the mounted directory and handle it in a way you would, any otherlocal �le. The �le can be opened up using a text editor; if it is a binary �le itcan be executed using the appropriate application or it can be opened up andoperated on using the UNIX system calls. As mentioned in an earlier section,the �le execution only takes place on the client machine and would have noimpact whatsoever on the remote server.

6.4.3 Open

On receiving an open() signal, the client application would establish a connectionwith the local cache and retrieve the �le handle that points to it. This �le handleis stored by the application in a data structure until the �le is released. Theopen function would receive information related to the virtual �le in the formof parameters from the kernel. Based on whether the �le to be opened is theone passed as one of the parameters in the form of the �le pathname or theinode number, the source �le located in the local cache is opened for readingand writing purposes.

Before opening the �le stored in the local cache though, the client sends anHTTP query to the server with the modi�cation time received with the lastretrieval. This is done to make sure that the latest version of the remote �leis presented to the user. If the �le has been modi�ed on the server, the serversends back the updated content along with the last modi�cation time for the�le. The cache is updated by the client along with the last modi�cation timefor the �le stored as a data structure in the client application.

49

6.4.4 Read

The read() system call results in the client application fetching �le content fromthe local cache containing the �le retrieved as a part of the �le retrieval activity.The �le handle stored in the open() function call is used to read data from thesource �le.

6.4.5 Write

The write() system call results in an update of the local cache containing the �lereceived during the �le retrieval activity in addition to an update of the original�le located on the remote server. The remote activity is carried out in a similarfashion to how the �le was originally received. A TCP connection is establishedbetween the client and the server though which the updated content with the�le o�set are sent to the server as an HTTP POST request. The request alsocontains the server part of the capability �le name. The server responds with thenew modi�ed time for the �le if the operation is successful. The time is updatedin the data structure maintained for this purpose in the client application.

6.4.6 Seek

The seek() operation is implemented by the FUSE �le system itself and doesnot require any extra functionality to be added. The seek operation simplymoves the �le pointer to the location referred to by the �le o�set passed as aparameter. Upon a subsequent read or write operation, the virtual �le systemitself calculates the new �le o�set based on the updated �le pointer moved usingthe lseek() system call. The activities are carried out on the original �le andthe local cache based on the �le o�set received as one of the parameters.

6.5 Capability File Server

The capability �le server, apart from hosting the �les corresponding to thecapability �le names would also be host to a Web application available over theHTTP protocol. This would require setting up of a web server such as ApacheTomcat or Glass�sh that are available for free over the internet. The applicationbeing hosted on the web server is developed using a script-based language suchas JSP or PHP that is able to carry out �le-based operations on the server.The application provides the ability to retrieve and update a �le based on theinformation stored in the capability �le name.

6.5.1 Parsing and Decrypting the Capability File Name

The HTTP request sent by the CapaFS client application contains the serverpart of the capability �le name along with the �le o�set that would be set toa value corresponding to the �le pointer location. The �le data to be updated

50

would be appended to the request when an update is required. The web appli-cation running over the Capability File Server receives such a request from theCapaFS client application and extracts the available information. The serverpart of the capability �le name obtained from the request is encoded and en-crypted so the �rst task of the application is to decode the encrypted bytes fromthe Unicode formatted server part. The application then decrypts the decodedserver part obtained from the earlier exercise using the symmetric key storedon the server.

The decrypted server part is then parsed for the complete �le path and accesspermissions to be granted on the �le. The �le name is checked for existenceand the access rights are analyzed according to the operation being carried out.Access rights are de�ned is a similar fashion to how the UNIX �le system de�nesthem. Three bytes are reserved for this purpose with each byte representing oneof three basic �le operations; namely, read, write and execute through `r', `w',and `x' respectively. A hyphen `-` is used when the operation is not permitted.

6.5.2 File Retrieval

Once the server part of the capability �le name has been extracted and parsed,the application is presented with the complete location of the �le on the serverand the access permissions. The �le is opened if it exists at the speci�ed locationand if the access rights suggest that the client is permitted to read the �le. Theserver also receives the last modi�ed time from the client which represents the�le's last modi�cation time when the last retrieval or update took place. Itis matched against the current last modi�cation time value. If the �le hasbeen updated after the last retrieval or update, the �le contents are read andtransmitted to the client in the form of an octet stream using a sizeable outputbu�er. In case the �le does not exist, cannot be read or has not been updatedsince last retrieval or update, an error message is sent back to the client asresponse.

6.5.2.1 Use Case

Actors: Capability File System (CapaFS), User

Purpose: To retrieve �le from the Capability File Server

Description: This use case allows the user to retrieve �le content from theCapability File Server based on the capability �le name.

Pre-Conditions

• The web server must be up and running with the Capability File NameServer Web Application providing �le retrieval and update features.

• The FUSE library must be installed.

• The Capability File System Client Application must be installed

• The capability �le name provided to the client application is syntacticallycorrect and has been parsed and tokenized.

51

Typical Course of EventsActor Action System Response

1 User initiates request for �le retrieval2 CapaFS checks whether the host

name or IP address provided is valid3 CapaFS establishes a TCP

connection with the Capability FileServer and stores the socketdescriptor representing the

connection4 CapaFS creates an HTTP POST

request conforming to HTTP 1.0standard with the encrypted serverpart of the capability �le name

appended at the end of the request5 CapaFS also attaches to the request

the last modi�ed time for the �le ifit is not being retrieved for the �rst

time.6 CapaFS sends the HTTP POST

request to the server through theTCP socket

7 System decodes the received serverpart of the capability �le name from

Unicode Formatting8 System decrypts the server part of

the capability �le name using theAES based symmetric key stored on

the server9 System parses the decrypted server

part and extracts the �le path on theserver and the access permission set

granted against the �le10 System checks whether the �le exists

on the server11 System matches the �le's last

modi�ed time with the time receivedwith the request

12 If the user has been granted the'read' permission, the �le is read andsent along with the new modi�cation

time back to CapaFS

52

Typical Course of EventsActor Action System Response

13 CapaFS receives the �le contentfrom the server and stores it in a

local cache maintained on the client�le system which will be used toretrieve �le content from here

onwards with the modi�cation timebeing used to determine whether anewer version of the �le is available

Alternative Course

Step 3

- If the host name or IP address is invalid, CapaFS returns an error message tothe user.

Step 4

- If the TCP connection is refused by the server, CapaFS returns an errormessage to the user.

Step 8

- If an exception occurs during the decoding activity, the system returns anerror message to CapaFS.

Step 9

- If an exception occurs during the decryption activity, the system returns anerror message to CapaFS.

Step 10

- If the extracted information is in an invalid format, the system returns anerror message to CapaFS.

Step 11

- If the �le does not exist, the system returns an error message to CapaFS.

Step 12

- If the �le's last modi�ed time is earlier than the time received with the request,the system returns an error message to CapaFS.

Step 13

- If the �le does not have 'read' permission against it, the system returns anerror message to CapaFS.

Post-Conditions

The �le content has been received completely and stored in the local cache.

53

6.5.3 File Update

Similar parsing activity takes place upon �le update which results in the serverpart getting decoded and decrypted. Again, it is checked whether the �le exists.Upon a successful outcome, it is checked whether the client has write accesspermission against the �le. The �le is then opened for modi�cation. The �lepointer is moved to the location referred to by the �le o�set included as a part ofthe HTTP request. Unlike the request received for the �le retrieval activity, �ledata to be written is appended to the update request. This �le data is written tothe �le from the location referred to by the �le o�set. Upon a successful update,the server sends the latest modi�cation time in response. Error messages aresent in case any of the above activities do not get executed successfully.

6.5.3.1 Use Case

Actors: Capability File System (CapaFS), User

Purpose: To update �le on the Capability File Server

Description: This use case allows the user to update �le content on the Capa-bility File Server based on the capability �le name created using the CapabilityFile Name Generation utility.

Pre-Conditions

• The web server must be up and running with the Capability File NameServer Web Application providing �le retrieval and update features.

• The FUSE library must be installed.

• The Capability File System Client Application must be installed

• The capability �le name provided to the client application is syntacticallycorrect and has been parsed and tokenized.

Typical Course of Events

Actor Action System Response

1 User initiates request for �le update2 CapaFS checks whether the host

name or IP address provided is valid3 CapaFS establishes a TCP

connection with the Capability FileServer and stores the socketdescriptor representing the

connection4 CapaFS creates an HTTP POST

request conforming to HTTP 1.0standard with the encrypted serverpart of the capability �le name, theupdated �le content and the �leo�set appended at the end of the

request

54

Typical Course of Events

Actor Action System Response5 CapaFS sends the HTTP POST

request to the server through theTCP socket

6 System decodes the received serverpart of the capability �le name from

Unicode Formatting7 System decrypts the server part of

the capability �le name using theAES based symmetric key stored on

the server8 System parses the decrypted server

part and extracts the �le path on theserver and the access permission set

granted against the �le9 System checks whether the �le exists

on the server10 If the user has been granted the

'write' permission, the �le is updatedwith the received contents startingfrom the location referred to by the�le o�set. A response is sent back to

CapaFS containing the latestmodi�cation time while indicatingthat the process was successful

11 CapaFS receives con�rmation fromthe server and updates the localcache maintained on the client �le

system accordingly

Alternative Course

Step 3

- If the host name or IP address is invalid, CapaFS returns an error message tothe user.

Step 4

- If the TCP connection is refused by the server, CapaFS returns an errormessage to the user.

Step 7

- If an exception occurs during the decoding activity, the system returns anerror message to CapaFS.

Step 8

- If an exception occurs during the decryption activity, the system returns anerror message to CapaFS.

Step 9

55

- If the extracted information is in an invalid format, the system returns anerror message to CapaFS.

Step 10

- If the �le does not exist, the system returns an error message to CapaFS.

Step 11

- If the �le does not have 'write' permission against it, the system returns anerror message to CapaFS.

Post-Conditions

The �le content has been updated completely on the server and local clientcache.

6.6 Summary

This chapter focused on how the Capability File Names would exist in a Dis-tributed File System. The functional speci�cations are presented based on theidea that the Capability File System would running on top of HTTP. The Capa-bility File Name Generation in addition to the �le retrieval and update activitiesare looked upon in the perspective of both the client and server. Use cases listingstep-by-step activities carried out in the three major activities are also presentedalong side.

56

Chapter 7

Design and Implementation

7.1 Top-level Architecture

Figure 7.1: CapaFS Top-level Architecture

As the �gure illustrates, there are two major components in the system ar-chitecture, the Capability File System running representing the client machine

57

and the Capability File Server hosting the �le resources. The Capability FileServer would also be hosting two web applications with one being used for thegeneration of capability �le names while the other being used for �le retrievaland update. The user hosting the �le server generates capability �le namesagainst �les using the Capability File Name Generation web application andshares them with trusted users. The users can then access the remote �le con-tent through the FUSE based client application. The FUSE application runningon a mounted directory on the user's local �le system would also maintain acache on the local �le system and use it retrieve and update contents of the �leretrieved from the server.

7.2 The Communication Protocol

7.2.1 Capability File Name Generation

Figure 7.2: Sequence Diagram for Capability File Name Generation

The �gure presents a sequence diagram illustrating the communication protocolfollowed during the Capability File Name Generation procedure. The client isrepresented by a web browser which will be communicating with the Capability

58

File Server web application. It initiates the communication by requesting theSSL certi�cate from the Capability File Server. The connection is establishedover HTTPS after which the user logs in through the Login web page by pro-viding its user name and password. The session is established and the user isforwarded to the Capability File Name Generation web page. Upon submissionof the required data, the server encrypts the server part of the capability �lename using an AES based symmetric key that only the server is aware of andresponds back to the user with the capability �le name. The client session endswhen the user clicks decides to log out or the session times out.

7.2.2 Capability File System - File Retrieval/Update

Figure 7.3: Sequence Diagram for File Retrieval/Update

The �gure presents a sequence diagram illustrating the communication protocolfollowed during the �le retrieval and update activities part of the Capability FileSystem. The CapaFS client application attempts to establish a TCP connectionwith the Capability File Server web application when a retrieval or updateis required. Once a connection is established, the client prepares an HTTPPOST request containing the capability �le name and other required informationand sends it to the server. The server retrieves the AES based symmetric keystored locally to decrypt the capability �le name and extract the necessaryinformation needed to proceed. Client is authenticated based on whether the

59

�le the Capability File Name refers to, exists or not. The operation requested isexecuted on the local �le based on whether the required permissions have beengranted against it. The server also takes into account the last modi�cation timethat is sent as a part of the response with every retrieval and update request andonly returns content if it has been modi�ed after the last retrieval or update.Finally, the server sends the reply based on the whether the operation wassuccessful or not and the session comes to an end.

7.3 Applied Technologies

This section will take a look at the di�erent sets of technologies that have beenused during the implementation of this prototype application. Some of themajor technologies and libraries used include FUSE, Java Server Pages, JavaKey Store and the Glass�sh and Apache Tomcat web servers. They are decribedbrie�y in the following sections.

7.3.1 FUSE over C

FUSE provides the ability to create a customized �le system running on top ofthe UNIX �le system. It provides a library that runs in user space and providesa way for its user to de�ne features speci�c to the virtual �le system. Theoriginal library made available by the FUSE creators can be utilized using theC programming language. Bindings for other programming languages such asJava, Python and C++ have been developed and are very much in use.

FUSE provides two types of interfaces that can be used to develop a �le system;standard and low-level. The Capability File System application for the client hasbeen developed using the low-level interface provided by FUSE. As described inmuch more detail earlier, the low-level interface provides signi�cant performanceimprovements over the standard interface since it operates more close to thekernel. The interface is slightly less friendly than the standard interface and isa bit similar to the kernel interface but it allows FUSE to operate in a moree�cient manner. C was very much the preferred choice since this low-levelinterface is available in C only.

7.3.2 Java Server Pages (JSP)

Java Server Pages provide a way to write scripts written in Java that are em-bedded into HTML web pages and allow the user to de�ne server-side logic inresponse to any requests received executing the web page. The concept of JavaServer Pages is similar to servlets in that they also allowed the server the abilityto include server related operations using Java inside HTML web pages. Butthe way servlets go about doing this is very di�erent to JSPs. Where servletsare Java class based containers for HTML pages, JSPs are the complete oppo-site since they are essentially HTML containers for Java classes and statements.JSPs also provide integration with Java beans which allows the programmer

60

to separate the business logic from presentation logic and allows the reuse ofcertain business related activities.

In the case of capability �le names, JSP plays host to the Capability File NameGeneration service and the Capability File System Retrieval and Update activi-ties. The reason the JSP was preferred over other similar platforms like PHP orASP was the feature set that usually accompanies the Java platform. Addition-ally, it provides more robustness and scalability. The Java Key Store presentedin the following section is one of the many features provided as a part of theJava platform.

7.3.3 Java Key Store

The Java Key Store provides a way to store keys and certi�cates in a safe andsecure manner. The feature comes as a part of the Java distribution kit and doesnot require any con�guration before it is employed. The information is storedas a �le in the local �le system with all the keys and certi�cates encrypted andcan optionally be protected by a user-de�ned passphrase. It is possible to usethe default key store �le as well create a new one. The �keytool� utility providedwith Java can be used to create and manage a key store. Additionally, the JavaSDK provides an API to carry out similar tasks programmatically.

The key store is used to maintain the SSL certi�cate for the Capability FileName Generation utility and the AES based symmetric key used for encryptingthe server part of the capability �le name. On �rst execution of either thecapability name generation procedure or the �le retrieval and update activitiespart of the Capability File Server web application, the key store is created usinga locally maintained passphrase.

7.3.4 Web Server � Apache Tomcat/ Glass�sh

The web server used to host the Capability File Name Generation applicationand the Capability File Server application should be one that supports hostingof the Java Server Pages. Glass�sh and the Apache Tomcat server are two suchplatforms that are freely available and support Java Server Pages.

7.4 The Server

This section will take a look at the Capability File Server and the di�erentfeatures that it provides. The focus would be on the Capability File NameGeneration application along with the �le retrieval and update activities andhow all of them �t together.

7.4.1 Capability File Name Encryption and Encoding

The Capability File Server hosts three JSP web pages providing features such ascapability �le name generation, �le retrieval and �le update. All of these features

61

are supported by the classes �CapaEncrypter� and �UnicodeFormatter� used forencryption and encoding purposes.

At the time the capability �le name is generated against a �le, the server partcomposed of the source �le path and the access permissions allowed against it isencrypted using an AES based symmetric key managed through Java KeyStore.The key is created the �rst time the generation activity or any of the �le retrievalor update activities is carried out.

The capability �le name is encrypted in the capability �le name generationprocedure through `CapaEncrypter' and is again used for decryption in the �leretrieval and update activities. The `UnicodeFormatter' class comes into playafter the encryption and decryption activities when it is used to encode anddecode into and from the Unicode format.

Additionally, SSL is employed over the HTTP server to allow communication totake place over a secure and encrypted channel. The certi�cate is created andmaintained through the Java Key Store as well through the use of the �keytool�utility.

7.4.1.1 CapaEncrypter

The 'CapaEncrypter' class provides three methods that are publicly accessible;namely, encrypt, decrypt and encryptPassword. The method 'setup()' is calledin the constructor function of the class and is declared as 'private'. The fourfunctions are brie�y described below,

void setUp()- The function fetches all the information needed to carry out theencryption and decryption operations. This involves fetching of the Java KeyStore �le stored on the server �le system from which the AES based symmetrickey used for the Capability File System is obtained. Upon �rst execution of theapplication, the function creates the Java Key Store and AES based symmetrickey used for encryption and decryption. The function creates a new 'Cipher'object that is provided with the Java distribution and is used to execute theselected encryption method on the provided data.

byte[] encrypt(String input) - The function carries out the encryption of datapassed on to it as the only parameter. The 'do�nal' funciton of the 'Cipher'object created during the setup activity is used to encrypt the input data whichin return produces a byte array that is sent back as the return value.

String decrypt(byte[] encryptionBytes) - The function carries out the encryptionof data passed on to it as the only parameter. The 'do�nal' funciton of the'Cipher' object created during the setup activity is used to encrypt the inputdata which in return produces a byte array that is sent back as the return value.

byte[] encryptPassword(String plaintext) - The function is used to compute anSHA(Secure Hash Algorithm) based hash of the text provided as input. It isused to calculate the hash representation of the password used in the Login andChange Password utilities.

62

Figure 7.4: Capability File Name Generation User Screen

7.4.1.2 UnicodeFormatter

The 'UnicodeFormatter' class provides two functions that allow conversion of abyte array to a Hexadecimal string and vice versa. The class is used to encodethe encrypted bytes obtained after the AES based encryption is carried out.The encoded version is presented to the user to be passed on to the CapaFSclient application. It is also used as a part of the retrieval and update activitieswhich involve decryption of the server part of the capability �le name after it isdecoded using this class.

7.4.2 Capability File Name Generation

One of the major tasks of the server is to provide the ability to generate capa-bility �le names. It does so by hosting a JSP based web application runningover a web server. This application provides a simplistic interface to the userwith an HTML form taking in as input the web server port number, the �lelocation on the server and the access permission in the form of Read, Write andExecute rights. Figure 7.1 presents the simple interface provided to the user.

Here is the sequence of steps executed in order to generate a capability �le name,

• When the form is submitted using the `Generate' button, the applicationvalidates the form for any input errors and noti�es the user accordingly.If the source �le does not exist or cannot be read, an error message isreturned in response with the user being asked to choose another �le. Ifeverything is the way it should be, the application goes on to carry outthe task of creating the capability �le name against the given arguments.

63

• The application determines the local IP address using the Java class `In-etAddress' allowing access to the local system information. The functioncall `InetAddress.getLocalHost().getHostAddress()' returns the IP addressof the local system.

• Next, the application goes about preparing the string representing theaccess permissions to be granted against the �le. The read, write andexecute permissions are represented by `r', `w' and `x' respectively. Thestring representation is initialized with `-` against each of the three accesspermissions. In case any of the three checkboxes was found marked, theinitial representation gets replaced by the appropriate character represen-tation.

• Once the access permission set is ready, it is appended to the �le locationseparated by a `/' to amount for the server part.

• The `CapaEncrypter' is initialized and the AES based symmetric key isretrieved from the key store once the server part is ready.

• The server part is then encrypted using the AES based key.

• All the parameters are then joined together to form the capability �lename. The pre�x of `/capafs' is attached followed by server IP address andserver port number making up the client part, and �nally the encryptedserver part encoded using the `UnicodeFormatter' class into hexadecimal.All of these parameters are separated by a `/'.

• Finally, the user is presented with the capability �le name in response.

7.4.2.1 Server Authentication

The server also provides an authentication mechanism that a user needs togo through in order to access the capability �le name generation utility. It isa simple login web page that requires a user name and password in order toproceed. At the moment, only a single user id `admin' is available with thepreset password of 'admin'. This password is stored as a hash value in a �leon the server and can be changed using the Change Password Utility. Thelogin information sent from the browser is encrypted through SSL which iscon�gured to run over the server. On a successful login, the user is forwardedto the capability �le name generation web page.

7.4.2.2 Change Password Utility

The Change Password Utility provides a simple interface through the webbrowser to allow the user to change its password. The utility can be accessedthrough the Capability File Name Generation screen on the click of a button.The users need to have been logged in before accessing this screen. The user isredirected back to the login screen otherwise. Through the Change Passwordscreen, the user can specify a new password that the application should use tolog in the user in place of the old one. The utility requires the user to enter

64

the new password as well as the old password even if the user is logged in. Norestrictions have been placed on the new password format as of yet. As men-tioned earlier, the application allows only the administrator given the login username 'admin', to log in to the Capability File Name Generation application.The password for 'admin' is also 'admin' when the application is accessed forthe �rst time. It is advised that the user change the temporary password assoon as possible to avoid getting victimized by an attacker.

7.4.3 File Retrieval

The server provides the ability to retrieve �le content located on the serverthrough an HTTP based application on the condition that the client requestingthe content possesses the capability �le name generated against it using thecapability �le name generation utility also being hosted on the web server. TheJSP based web page accepts HTTP POST requests containing the informationneeded to access the �le and based on whether the information is legitimate ornot, sends back the desirable �le content. The procedure follows the sequenceof steps listed below,

• On receiving a valid HTTP POST request, the application parses theheader to extract information needed to retrieve �le content.

• The attribute referred to by `�lename' is extracted. The value containedrepresents the server part of the capability �le name.

• The obtained value is �rst decoded using `UnicodeFormatter' which inreturn produces bytes that are passed onto `CapaEncrypter'.

• `CapaEncrypter' then based on the AES based symmetric key obtainedfrom the local Java Key Store, decrypts the server part and returns thedecrypted content which contains the local �le path and the access per-missions granted against it.

• The �le path is checked for existence and readability.

• The last modi�ed time received with the request is matched against thelatest modi�cation time.

• Information is extracted from the access permission set to determine whetherthe �le can be read or not.

• The server responds back with an empty string if the �le content cannotbe retrieved or if the read access permissions have not been granted to theuser. The same response is returned if the �le has not been modi�ed sincethe last retrieval or update.

• If the access permission set contains the read permission, the �le is readand the response is prepared to be sent.

• The �le content is read and written to the output stream using a bu�erof 8092 bytes until end-of-�le is reached.

• The �le input stream is released and the response is sent back to the client.

65

7.4.4 File Update

The �le update utility is also hosted as a JSP based web page on the web serverand provides the ability to make modi�cations to a �le located on the serverand referred to by the capability �le name. The update web page similar tothe retrieval procedure also expects an HTTP POST request containing theinformation needed to update the �le pointed to by the capability �le name.The following sequence of steps is executed in relation to this activity,

• On receiving a valid HTTP POST request, the application parses theheader to extract information needed to update �le content.

• The attribute referred to by `�lename' is extracted. The value containedrepresents the server part of the capability �le name.

• In addition, the �le o�set referred to by `�leo�set' in the request is ex-tracted and contains the �le pointer location from which the applicationis supposed to start writing on the �le.

• Finally, the value pointed to by `�ledata' contains the �le content that isto be written.

• The obtained server part value is �rst decoded using `UnicodeFormatter'which in return produces bytes that are passed onto `CapaEncrypter'.

• `CapaEncrypter' then based on the AES based symmetric key obtainedfrom the local Java Key Store, decrypts the server part and returns thedecrypted content which contains the local �le path and the access per-missions granted against it.

• The �le path is checked for existence and readability.

• Information is extracted from the access permission set to determine whetherthe �le can be modi�ed or not.

• If the write permission has been set, the �le content is written on the �lelocated on the server starting from the o�set value.

• On successful completion of the procedure, a value of `0' is returned backto the server along with the latest modi�cation time.

• In case of an error at any stage, a value referring that error is returned.

7.5 The Client

This section will take a look at the client-side implementation of the CapabilityFile System. The FUSE �le system implementation will be in focus along withthe �le retrieval and update activities. This section will also take a look athow the client cache is implemented and utilized as a part of the CapaFS clientapplication.

66

7.5.1 File Retrieval

The client application is responsible for retrieval of the remote �le referred to bythe capability �le name at the time it is looked up on client side. The parsingactivity taking place in the beginning parses the capability �le name to extractthe client and server parts. The client part is used to communicate with serverwhile the server part is sent along with the HTTP requests that are created asa part of the retrieval activity. Upon successful execution, the �le is stored inthe cache maintained on the local �le system. The following series of steps iscarried out during the �le retrieval activity at client-side,

• The capability �le name is looked up on the client �le system and is passedto the client application as one of the arguments.

• The capability �le name is parsed by the client application to extract theclient and server parts. The client part is composed of the pre�x `capafs', the server IP address and the server port number while the server partcontains the original �le path on the server and the access permissiongranted against it although for the server it is just an encrypted string.

• The format of the capability �le name is checked with matching of thepre�x `capafs' being the �rst in a line of tests.

• The IP address is extracted next and is checked for validity followed bythe port number.

• The encrypted server part is stored in a data structure.

• A Transport Control Protocol (TCP) socket connection to the server isestablished using the IP address and port number. An error is returned ifthe connection is refused.

• Upon a successful connection, an HTTP POST query containing the serverpart of the capability �le name and the �le's last modi�ed time is prepared.

• The POST query prepared conforming to the HTTP 1.0 standard is sentover the TCP connection.

• The application attempts to receive a reply from the server. A failureresults in the user getting prompted with an error through the applicationtrying to present the �le content.

• On a valid response from the server, the header is parsed and the �le con-tent is received using a bu�er of the size referred to by the macro BUFSIZwhich is calculated based on the compiler being used. The content receivedis written on the �le handle pointing to the local cache.

• If the �le has not been updated since last retrieval or update, no contentis received from the server and the client returns the �le stored in cachein response.

• Upon completion of this activity, the socket connection between the clientand server is closed.

• The session continues to run until the terminal running the application isstopped or if there is a fatal error.

67

7.5.2 FUSE File Operations

As described earlier, FUSE allows users to de�ne their own functionalitiesagainst operations carried out in a �le system. Although FUSE provides thisfeature for a number of operations ranging from something like opening a �le tocreating a symbolic link or deleting a �le, only the ones necessary for the imple-mentation of the prototype for this project have been utilized. All of the func-tions are required to be declared as static for them to work properly in FUSE.Additionally, all of these functions are passed through the `fuse_operations'structure to the `fuse_lowlevel_new' functions at the time of initialization.They are presented below,

7.5.2.1 Lookup

void capafs_lookup ( fuse_req_t req , fuse_ino_t parent ,const char ∗name)

The lookup function gets called every time a directory entry is looked up usingits name. This is the point where the inode of a �le or folder is de�ned. Theparent inode for the root directory is `1', so based on the parent inode and the�le name it can be determined where we are in the directory chain. Based onthe information available the current �le's inode number is determined. In thecase of CapaFS, there is a maximum of three levels in a directory chain. Inodes'3' and '4' are used to represent the �rst and second level directories. The rootdirectory is the only one that can be listed and appears to contain no �les andfolders upon a lookup. The other two directories cannot be listed and wouldresult in an error if a lookup is made against them. The three directories formthe client part of the capability �le name. The second level directory wouldcontain the �le representing the capability �le name server part.

The inode number '2' is used to indicate a new �le request and subsequentlyresults in the content being requested from the server. Once the content hasbeen received, a new inode number is assigned to the �le starting from '5'.The capability �le name is stored against the inode number in a list which isreallocated upon every new �le being requested. The cache �le would containthe content received in the �le retrieval activity. The inode number is returnedalong with other �le attributes obtained through the `Stat' or `GetAttr' function.A call with the return variable of type `fuse_entry_param' is made to the`fuse_reply_entry' function that is part of the FUSE low-level interface and isdesigned speci�cally for the generation of response against the lookup functioncall.

7.5.2.2 Getattr

void capa f s_getat t r ( fuse_req_t req , fuse_ino_t ino ,s t r u c t f u s e_ f i l e_ in f o ∗ f i )

The `GetAttr' performs the role of the glibc `lstat' system call which is to returnthe attributes associated with a particular �le. The inode number referringto the �le in CapaFS is passed as one of the parameters based on which the

68

attributes are retrieved. If this inode number matches the one set in the lookupfunction call, the information against the �le is retrieved using a glibc `lstat'system call against the cache �le containing the original �le content receivedduring the �le retrieval activity.

The �le attributes are returned using a special `stat' structure which is �lledup through the `lstat' function call. In case, the inode parameter refers tothe parent directory, the structure �elds are updated manually. `st_mode' isupdated with a value of `S_IFDIR | 0755' where IF_DIR is equal to `0040000'which sets the �le as a directory and is then binary added to `0755' giving it thenormal �le permissions. Another value `st_nlink' which de�nes the number ofhard links against an inode is updated with a value of `2' since it is a directoryitself and does not have any sub-directories. The structure's inode number isalso updated with the passed parameter. The response is returned using theFUSE `fuse_reply_attr' function meant for the `GetAttr' operation.

7.5.2.3 Readdir

void capaf s_readdi r ( fuse_req_t req , fuse_ino_t ino ,s i z e_t s i z e , o f f_t o f f , s t r u c t f u s e_ f i l e_ in f o ∗ f i )

The `readdir' operation is used to list the contents of a directory. When called,the application prepares the list by adding entries into the directory bu�erusing a special structure `dirbuf' containing a character string that is passed asa parameter to the FUSE library function `fuse_add_direntry'. This functionis also used to determine the size of the entry before eventually adding it to thebu�er.

Entries are made `.' and `..' that represent the current and parent directoriesrespectively. Only the contents of the root directory can be listed. The returnvalue is a character string that contains the directory contents listed one afterthe other.

7.5.2.4 Open

void capafs_open ( fuse_req_t req , fuse_ino_t ino ,s t r u c t f u s e_ f i l e_ in f o ∗ f i )

The open function is called when a �le gets opened in the capability �le system.Since the FUSE low-level interface has been used in the development of CapaFS,the function call only gets the inode number of the �le being opened. Throughthe standard interface, the complete �le path on the local �le system would havebeen available as one of the parameters instead of the inode number.

With only the inode number available, the application matches it against theinode number de�ned in the lookup function. If a �le represented by this inodeexists in the cache, the application makes the glibc open system call againstit and retrieves the �le handle in return. Before making the system call, theapplication sends a query to the remote server to determine whether it has thelatest copy of the requested �le. The �le handle is stored in the �fuse_�le_info�structure passed as an argument and is returned through the �fuse_reply_open�function that is part of the FUSE low-level interface and is designed speci�cally

69

for the generation of response against the open function call. In addition, a listmaintained against inodes in the Capability File System session is also updatedwith the new �le decriptor.

7.5.2.5 Read

void capafs_read ( fuse_req_t req , fuse_ino_t ino ,s i z e_t s i z e , o f f_t o f f , s t r u c t f u s e_ f i l e_ in f o ∗ f i )

The read operation fetches �le content from the cache store locally on the �lesystem. This is done using the `pread' system call which fetches content from the�le represented by the �le handle stored in the `open' operation. In addition ittakes the current o�set located somewhere inside the �le as one of the arguments.This value is contained in one of the parameters passed onto the read operationby the �le system.

File content is read only if the inode corresponds to the inode number represent-ing the �le fetched from the remote server. The read operation allows variablenumber of bytes to be read in a single function call. Usually a large �le is brokenup into multiple read calls and a portion of it is read every time into the bu�er.The o�set gets updated accordingly at every function call based on which the�le content is read and �lled into the bu�er. This bu�er and the number of bytesread are returned as a part of the FUSE low-level reply activity which is carriedout through the `fuse_reply_buf' function meant for the read operation.

7.5.2.6 Write

void capafs_write ( fuse_req_t req , fuse_ino_t ino ,const char ∗buf , s i z e_t s i z e , o f f_t o f f ,s t r u c t f u s e_ f i l e_ in f o ∗ f i )

The write function is responsible for updating the �le content received throughthe bu�er to the �le cache and to the remote server using the �le update activityde�ned in Section 7.5.3. The local cache is updated using the `pwrite' systemcall which is provided with the updated content as well as the �le o�set pointingto the �le location at which the data is to be written.

The write bu�er, similar to the read bu�er can only hold a limited number ofbytes. So on every function call, the application receives a maximum of 4096bytes with the o�set updated accordingly. This could result in a performancelimitation if the remote server is also updated every 4096 bytes. So if the �lecontent contains more than 4096 bytes, then the application waits until all ofthe content has been received and only then sends a request for update to theremote server. A local bu�er is maintained which is updated on every call andis sent along with the update request to the remote server. The �le o�set alsopoints to the starting location from which the �le content should be modi�ed.Additionally, in case the end of �le has been reached and detected, the rest ofthe �le is truncated.

The number of bytes written is the return value passed on to the `fuse_reply_write'function which sends back the response to the �le system. The last modi�ed time

70

is also updated in the process. An error is returned using the `fuse_reply_err'function if any of operations fails during the execution.

7.5.2.7 Setattr

void capa f s_se ta t t r ( fuse_req_t req , fuse_ino_t ino ,s t r u c t s t a t ∗ att r , i n t to_set , s t r u c t f u s e_ f i l e_ in f o ∗ f i )

The implementation of the SetAttr function is a requirement for the write op-eration to function properly. The function goes hand in hand with every writeactivity and requires certain attributes to be updated manually on the original�le such as size, access time and modi�ed time of the �le. And this is essentiallywhat the function does. Since the `GetAttr' function fetches these attributesfrom the local cache, so that is where the update takes place.

A call to the glibc `utime' function is made to update the �le access and modi-�cation times. The `stat' structure variable is updated as a part of this activityand returned through `fuse_reply_attr' function call.

7.5.2.8 Destroy

void capafs_destroy ( )

The destroy function gets called at the end of a FUSE session which takes placewhen the mounted directory is released. The function is used to carry outsome cleaning activities involving freeing up of memory allocated to pointers inaddition to releasing �le handles for �les opened during the FUSE session suchas the CapaFS log �le.

This function gets called after the FUSE client session is stopped. In addition,the mount directory on which the FUSE session has been running is unmountedafter which it gets removed from the local �le system by the client application.Finally, the local cache being maintained on the client �le system is deleted anda new copy gets created, updated with the latest �le content if the FUSE sessionis run again.

7.5.3 File Update

The �le update activity is carried out right after a �le write has taken place. Ifthe content to be updated is larger than 131072 bytes, it is received in blocksof 131072 bytes which are placed in a bu�er and stored until all of the datahas been received upon which the �le update activity is executed on the remoteserver hosting the original �le.

The connection between the client and server is established in a way that issimilar to the �le retrieval activity. Upon a successful connection the updatedcontent received from the �le system is sent to the remote server along withthe server part of the capability �le name. As described earlier, the local cacheis updated on every write request received using the `pwrite' system call. Thesequence of steps executed in the �le update procedure is presented below,

• A Transport Control Protocol (TCP) socket connection to the server isestablished using the IP address and port number obtained at the start of

71

execution of the client application. An error is returned if the connectionis refused.

• Upon a successful connection, the HTTP POST query containing theserver part of the capability �le name, the �le o�set and the updated �lecontent is prepared which is to be sent to the server through the socket. Asmentioned earlier a bu�er is maintained for the updated �le content whichis added to the bu�er upon every write call made containing a maximumof 4096 bytes.

• The POST query is prepared conforming to the HTTP 1.0 standard andsent over the TCP connection.

• The application attempts to receive a reply from the server. A failureresults in the user getting prompted with an error and the applicationreturning the user to the UNIX shell.

• On a valid response from the server, the header is parsed and the �le con-tent is received using a bu�er of the size referred to by the macro BUFSIZwhich is calculated based on the compiler being used. The returned valueindicates whether the update was successful or not. The last modi�edtime is also returned as part of the response by the server and is updatedlocally.

• Upon completion of this activity, the local bu�er being maintained for theupdated �le content is released.

• Additionally, the socket connection between the client and server is closed.

7.5.4 Client Cache

The client application maintains a cache on the local �le system that is usedto store the �le content received during the �le retrieval activity. The cacheis maintained as a �le in `/tmp/capafs/capafs_source' folder on the local �lesystem. The folders representing the cache are created the �rst time a �le isretrieved from the server. The cache is updated during every open() functioncall depending on whether the remote �le content has been modi�ed after thelast retrieval or update.

The operations de�ned as part of the FUSE implementation are mapped againstthis local cache and all activities are executed using the �le handle obtainedagainst this cache on the open function call. This �le handle is maintaineduntil the �le is released by the user. The read operation results in data beingretrieved from this cache instead of having to access it from the server everytime it is read. Upon the write operation though, in addition to the local cachebeing updated the remote �le content is also sent the updated content.

7.5.5 Logging

A log �le is maintained in the `/tmp/capafs' folder on the local �le system whichcontains basic information related to the activities that are carried during a

72

particular client session. The log �le is maintained per �le so only the lastsession against a particular �le would be available for analysis. In addition tobeing used for auditing purposes, this log �le can also be used as a source fortroubleshooting in case any activity malfunctions.

7.6 Summary

This chapter provided a detailed description of the design and implementationof the Capability File System. It expands on the previous chapter in that itprovides description of activities in terms of the technologies and libraries beingused for this project which include FUSE, JSP, etc. A detailed depiction of theCapability File Name Generation procedure and the �le retrieval and updateactivities is provided with focus on how the di�erent technologies have beenused to implement them. Features such as client caching is further elaboratedon as well considering that it is one of the integral parts of the CapaFS clientapplication.

73

Chapter 8

Evaluation

This section documents the analysis and evaluation carried out on the prototypeimplementation of the Capability File System using HTTP.

8.1 Functionality Evaluation

This section presents the functionality tests that were carried out on the Capa-bility File System server and client applications. Most of the tests that followcan be categorized as black box tests and although some white box tests werecarried out during the process but they have not been documented.

8.1.1 Capability File Name Generator

Before running any of following tests the user must ensure that the web server isup and running with the web application part of the Capability File System soft-ware distribution deployed according to the instructions provided in AppendixA.1.

8.1.1.1 Login Utility

The application provides only the one user in the form of `admin'. The initialpassword for the `admin' user is also `admin' but can be changed using theChange Password Utility. Following is a series of tests that were carried out onthe login utility,

• Open the login pageResult - The server displays the login screen to the user.

• Enter correct user name and password and click loginResult - The server redirects the user to the Capability File Name Gener-ation utility located at the address �http://[hostname or IP address]:[PortNumber]/CapaServer/generate_capa_name.jsp�.

74

• Enter incorrect user name and password and click loginResult - The server displays an error saying �Invalid User name or Pass-word�.

• Enter correct user name and incorrect password and click loginResult - The server displays an error saying �Invalid User name or Pass-word�.

8.1.1.2 Capability File Name Generator

• Open the generator web page with loginResult - The server displays the capability �le name generation screen asin Figure 7.1.

• Open the generator web page without loginResult - The server redirects the user back to the login screen.

• Enter valid �elds and click on GenerateResult - The server generates the capability �le name against the �le path,port number and access rights provided as input and displays it back tothe user.

• Leave �elds empty and click on GenerateResult - The server asks the user to enter the complete �le path on theserver by displaying the error message saying �Please enter the File ServerPath�.

• Enter invalid port number and click on GenerateResult - The server asks the user to enter a valid port number by displayingthe error message saying �Please enter a valid Port Number�.

• Enter invalid �le path and click on GenerateResult - The server asks the user to enter a valid port number by displayingthe error message saying �Please enter a valid File Path�.

• Select no access rights and click on GenerateResult - The server generates the capability �le name against the �le path,port number but without any access rights and displays it back to the user.

• Try di�erent combinations of access rights and click on GenerateResult - The server generates the capability �le name against the �le path,port number and the access rights selected no matter what they are anddisplays it back to the user.

8.1.1.3 Change Password Utility

• Open the Change Password Utility without loginResult - The server redirects the user back to the login screen, which isthe expected response from the server.

• Open the Change Password Utility with loginResult - The server displays the Change Password screen.

75

• Open the Change Password Utility using the link provided onthe Capability File Name Generation web pageResult - The server displays the Change Password screen.

• Click on the Change Password button with empty �eldsResult � The server displays an error message asking the user to enter themissing �elds.

• Click on the Change Password button with an incorrect old pass-wordResult � The server displays an error message asking the user to enter thecorrect old password.

• Click on the Change Password button with mismatched newpasswordsResult � The server displays an error message asking the user to enter thesame new passwords.

• Click on the Change Password button with valid old and newpasswordsResult � The server displays a message saying that the password waschanged successfully.

8.1.2 CapaFS Client Application

• Run the CapaFS client application after following the installa-tion instructions in Appendix A.3Result � The application starts successfully

• Open a valid capability �le name using the terminalResult � The �le is opened using the application containing the expectedcontent.

• Open a valid capability �le name through a symbolic linkResult - The �le is opened using the application containing the expectedcontent.

• Open an invalid capability �le nameResult - An error message is displayed by the local �le system. The mes-sage depends on the application being used to open the �le. The messagein general looks like,�Please check that you typed the location correctly and try again�

• Open a capability �le name with valid client part but invalidserver partResult - An error message is displayed by the local �le system. The mes-sage depends on the application being used to open the �le. The messagein general looks like,�Please check that you typed the location correctly and try again�

• Open and list contents of mounted directory `/capafs'Result � The directory contains no �les or folders.

76

• Open a capability �le name comprising of only the client partResult - An error message is displayed by the local �le system. The mes-sage depends on the application being used to open the �le. The messagein general looks like,�Please check that you typed the location correctly and try again�

• Open retrieved �le through the glibc system callResult - The call returns a �le descriptor successfully.

• Read �le through the glibc system call into a bu�erResult � The call results in content being read into the bu�er from thestart of the �le to the size speci�ed.

• Read after a Seek on the �le through the glibc system callResult � The content read into the bu�er of size `s' is from the seek location`l' to the location `l+s'.

• Write on �le through the glibc system callResult � The call results in content being written to the remote �le fromthe start of the �le to the size speci�ed.

• Write after a Seek on the �le through the glibc system callResult � The content of size `s' is written onto the remote �le from theseek location `l' to the location `l+s'.

• Read �le using a GUI-based editor such as geditResult � The whole �le content is readable through gedit.

• Write on �le using a GUI-based editor such as geditResult � Content is updated accordingly on the server when the �le issaved in gedit.

• Truncate �le using a GUI-based editor such as geditResult � The �le gets truncated successfully

• Partially truncate �le using a GUI-based editor such as geditResult � Only the part truncated is missing from the original �le and therest of the content stays intact.

• Retrieve a large �le from the server (>50 MB)Result � The �le is retrieved successfully

• Retrieve a binary �le from the serverResult � The �le is retrieved successfully and can be run using appropriateapplications. Test was successfully carried out for documents(doc/pdf),audio/video �les, images, etc.

• Update a relatively large �le on the server (>10 MB)Result � The �le gets updated successfully on the server.

• Open more than one �leResult � All �les opened simultaneously can be operated upon withoutany malfunction.

77

• Attempt a read on a �le against which no read permission hasbeen grantedResult - An error message is displayed by the local �le system. The mes-sage depends on the application being used to open the �le. The messagein general looks like,�Please check that you typed the location correctly and try again�

• Attempt a write on a �le against which no write permission hasbeen grantedResult - An error message is displayed by the local �le system. The mes-sage depends on the application being used to open the �le. The messagein general looks like,�Permission Denied�

8.2 Security Analysis

The Capability File System provides a secure way for users to access and sharetheir �le resources over the internet. The next few sections would take a lookat how secure the communication between the client and server is in relation tothe various functions provided by the Capability File System.

8.2.1 Server Part Encryption

The server part in a capability �le name is encrypted using an AES basedsymmetric key to ensure that only the server is able to decrypt the contentwithin. This key is stored on the server in a Java Key Store which allows accessto the key only through the application and is password protected. The keystore and the key are created the �rst time the CapaFS Server web applicationor the Capability File Name Generation application is executed.

The key uses 128-bit encryption to encrypt and decrypt the server part of thecapability �le name. The 128-bit key provides adequate level of security alongwith performance e�ciency. The key is known only to the server and is usedduring the �le retrieval and update activities.

8.2.2 Communication over SSL

The capability �le name generation procedure is carried out over a secure chan-nel in the form of SSL ensuring that all communication taking place betweenthe user and the server is encrypted and inviolable.

8.2.3 Con�dentiality

The Capability File System makes sure that the information contained in thecapability �le name and relevant to only the server is encrypted and not vis-ible to any unauthorized users. The delegation procedure as well ensures thiscon�dentiality. This means that if any unauthorized user gets access to the

78

capability �le, it will not be able to determine the �le location on the server andthe permissions granted against it.

One of the limitations of the client application though is the inability to encryptthe requests being sent to the server that contain the capability �le name. Soan attacker that intercepts messages between the client and server would beable to get hold of the capability �le name and execute operations on its own.This can be solved by having the application run on top of an SSL layer whichwould result in all communication between the client and server being encrypted.Section 9.2.1 describes the solution in a bit more detail.

The Capability File Name Generation, on the other hand, ensures completecon�dentiality of all the messages being exchanged between the user and theserver application. It manages to achieve this through the use of SSL which isimplemented on the server. With a web browser supporting SSL certi�cates, theuser is able to communicate with the server without any threat of informationleakage.

8.2.4 Integrity

The capability �le name structure ensures that the part meant for the server isprotected from manipulation of any sort until it gets to the server. The serverpart is encrypted using an AES based symmetric key which is accessible bythe server alone. So when a capability �le name is presented to the server, itis able to decrypt it using that key. The client part which is meant for theclient is not encrypted and can be modi�ed if deemed necessary by the clientbut any modi�cation from an attacker would have no impact on the server partwhich stays intact from the time it is generated to the time that it becomesuseless. Furthermore, it is not possible to reuse the encrypted part in a waythat it provides access to some other �les that the user is not meant to. AESensures that the encrypted versions are in no way related to their decryptedcounterparts.

The Capability File Name Generation application would be running over SSLwhich relies on both parties authenticating each other and ensures messageintegrity.

8.2.5 Availability

The Capability File System architecture is structured in a way that there isnever a need for any third parties to get involved. So, essentially the reliabilityand availability factor of the server application rests with the user hosting theserver itself. The Capability File Name Generation application is again hostedby the �le server meaning that the user acting as the host server would beresponsible for making sure that the server and the required services are up andrunning. But since the content is located on the server as well, the availabilityfactor is not all that necessary meaning that if the content is not available thenit does not matter whether the web server is running or not.

79

8.2.6 Authenticity

The Capability File System is designed such that the Capability File Namesthemselves act as the authentication device which makes the delegation processeasier and allows the hosting user to share �les with even unauthorized users.This means that the Capability File Server application does not really need toknow the identity of the client. An improvement over the original CapabilityFile Name is presented in Section 5.1.6 which describes a way to introduce clientauthentication for auditing purposes.

Server authentication is not a part of the original Capability File Name structurebut can be introduced as explained in Section 5.1.5. Lack of server authentica-tion does pose a slight threat to the user since it has no way to know if the hostit is communicating with is the server where the �le resides.

8.3 Performance Evaluation

The capability �le system runs on top of the HTTP protocol and is meantto be used within Wide Area Networks. Using the capability �le system in aLocal Area Network is possible of course and would result in clearly noticeableimprovements in performance but the idea behind the project was to provide away to communicate over the internet without having to go through �rewalls.This was accomplished through the use of HTTP and so some tests were carriedout in wide area networks to give an idea of how this concept would fare in thereal world.

NFS is considered very much the benchmark when it comes to distributed �lesystems and so this section would mainly be focusing on how CapaFS performsin comparison to NFS. Tests were carried out on Intel Core 2 Duo Processorbased machines with 2 Gigabytes of memory. Additionally, some similar testswere performed on the Ubuntu-based local File System of the client machine.The server, on the other hand ran Windows 7 as the host operating systemwith GlassFish as the web server. Open, Read and Write system calls weremade against a �le on the local �le system, a �le on an NFS mounted directoryrepresenting an NFS server share and a �le on the CapaFS mount location. Thesame �le is placed on each of the three locations containing text content makingup a total of around 10 Megabytes. The Read and Write operations are carriedout using a bu�er of around 5 Megabytes. Table 8.1 presents the time in secondsit takes to execute each of the system calls,

Activity LocalFS (sec) CapaFS (sec) NFS (sec)

Open (10 MB) 0.000007 1.64 0.0011Read (5 MB) 0.0075 0.0095 0.0075Write (5 MB) 0.0035 0.081 0.0045

Re-open (10 MB) 0.000011 0.0071 0.00028Re-read (5 MB) 0.0032 0.0048 0.0034Re-write (5 MB) 0.0035 0.21 0.0045

Table 8.1: Execution Time for System(LocalFS vs CapaFS vs NFS)

80

As clearly observable from the test results, the Capability File System performsrather well in comparison to NFS when it comes to reading and writing contentfrom and to the remote �le. It is only during the open operation that we see itunderperforming. This is mainly due to the time it takes to receive the bu�eredstream on client side. Since the connection is established through a TCP socket,the number of bytes received on each system call is limited to the TCP receivewindow size. The receive window size is con�gurable up to a certain limitbeyond which it has to be con�gured through the kernel TCP/IP stack. Witheach `recv()' system call taking up to 250 milliseconds to fetch data rangingfrom 4 Kilobytes to 128 Kilobytes, the total time needed to receive a �le of 10Megabytes adds up to around this much time.

One solution to this problem is to implement a non-blocking receiving mech-anism that can be achieved through the fcntl() system call on the socket �ledescriptor. The problem with this solution is that it requires the sender toalso be non-blocking which is a feature that JSP does not provide. The OutputStream sent as a response to an HTTP request for the JSP page is always block-ing and there is no way to do it any other way. Certain performance tuningmeasures may help improve this execution time and will be looked over in thefuture. Additionally, the cost of decrypting the server part also plays a role inthe delay but has a comparatively lesser impact on the overall execution time.

Certain performance improvement measures were taken that resulted in fasterexecution times. The FUSE `direct_io' feature, when enabled shows signi�cantimprovements in write() system call execution times and has been enable for all�les. Additionally, the socket bu�er size of 8 Kilobytes was chosen such thatprovided the best possible results. The TCP receive and send window bu�erswere also adjusted accordingly. All of these performance improvements come asa part of the client application and require no further con�guration.

8.4 Summary

This chapter focused on evaluation of the Capability File System client andserver applications. Tests carried out to test the di�erent functionalities werebrie�y described. A complete section is dedicated to the security analysis ofthe server and client applications. Finally, performance of the Capability FileSystem is measured and comparisons are made with NFS and the Linux �lesystem.

81

Chapter 9

Conclusions and Future Work

9.1 Conclusions

Network �le systems have been in use ever since there was felt a need to shareinformation with users over a network. These networks have grown in magni-tude considerably over the years. What started o� as a single network with fewcomputer hosts connected using a single switch, now has billions of users con-nected over networks spanning the entire world. The network �le systems cameinto play soon afterwards and in the form of NFS, AFS and CIFS have ful�lledthe purpose to a great extent. This project aims to provide a completely newway of sharing �les through a concept based on Capability File Names allowingsafe and secure sharing of resources over the internet.

The Capability File System based on the idea of Capability File Names operatessimilarly to other network �le systems in the way that it provides an interfaceto the user that makes the remote �les appear as local �les and allows its usersa chance to carry out the same kind of activities as they would on a regular �lelocated on the �le system. But that is about the only thing that the CapabilityFile System has in common with the likes of NFS, AFS or even CIFS andprovides a number of features that most of them do not catering to some of thelimitations that they accompany. Here is a list of features that the CapabilityFile System o�ers,

• The Capability File System runs over HTTP making it a perfect solutionfor Wide Area Networks (WAN) since most �rewalls these days allowHTTP tra�c to go through them in comparison to other network �lesystems which usually run a service on top of the transport protocols suchas UDP and TCP.

• The Capability File Name allows the authentication and authorizationprocess to take place through the name itself. It does so by storing thepermissions granted against a �le encrypted inside the �le name. Thename itself also acts as the authentication device and is used by the serverto authenticate the client.

82

• Capability File Name allows access control permissions to be de�ned forindividual �les.

• Capability File Names provide an extremely simple way of delegatingrights to other trusted users and can be done just by sharing the capability�le name with them.

• Capability File System negates the need to have any third party involvedin any of the proceedings. To add to this, there is not even a need for anyshared central storage location as all the sharing parties can share their�les from their own �le systems and the others can access them by justreferring to the capability �le name.

9.2 Future Work

9.2.1 SSL based Client application

The current prototype version of the Capability File System allows �le sharingover the internet while running on top of the HTTP protocol. The exchange ofinformation between the client and server during the �le retrieval and updateactivities is done using the standard HTTP requests and responses without anyencryption. This poses a huge threat to the application user since it allows any-one intercepting messages between the client and server to observe and extractinformation. As discussed earlier in Section 8.2 as a part of the security analysisof the application, this is a clear vulnerability which although will not compro-mise the server by any means, but still could result in potential exploitation bythe attacker. It is suggested that the communication takes place over a safe andsecure channel but since that is not always the case, there is a need to makesure that all data exchanged between the client and server is con�dential evenon insecure networks.

This con�dentiality can be achieved through the use of the Secure Socket Layer(SSL), a feature available for HTTP that adds a secure layer on top of HTTPthus making sure that all communication taking place between the connectingparties is encrypted. The protocol is known as the Secure Hypertext TransferProtocol (HTTPS). With messages being exchanged through HTTPS, it wouldnot matter whether the network underneath is secure or not as all the informa-tion exchanged.

Using the current set of technologies, this can be accomplished on the server-side by using the SSL certi�cate used as a part of the Capability File NameGeneration activity. On the client-side, there would be a need to implementSSL functionalities through the use of an open source library available for Cby the name of �OpenSSL�. OpenSSL provides all the functionalities needed tosend and receive messages over HTTPS.

9.2.2 Performance Tuning

A deep understanding of concepts and technologies such as FUSE, the TCP/IPstack and the UNIX �le system and processes is required to be able to achieve

83

the optimum level of performance for the Capability File System. Although aconsiderable amount of time was spent in relation to this, there is still a roomfor improvement. The �le retrieval activity has been the main cause of concernin terms of performance and the use of non-blocking reads is something thatcan be attempted to make the times faster. Since there are certain limitationswith respect to non-blocking writes in JSP, this is something that can be lookedupon. In addition to the synchronous non-blocking operations, the asynchronousread and write operations in the form of aio_read() and aio_write also providefeatures that can be explored and utilitzed to the application's bene�t.

The di�erent TCP/IP options can also be tweeked slightly. Setting the optimalsend and receive window sizes can result in improvements in performance. Inaddition, making modi�cations to the TCP/IP stack con�guration is an optionthat can result in greater e�ciency in data transfers.

84

Appendix A

Installation

A.1 Installing the Server Applications

The Capability File Server web application can be installed on either ApacheTomcat or the Glass�sh server. Installation should be carried out similar toany other web application. The installation steps to be followed for Tomcat arepresented below,

• Install the Tomcat web server.

• In Windows, place the folder in the webapps directory of your Tomcatfolder. Similarly, the folder needs to be placed in the �/var/lib/tom-cat6/webapps� folder in Linux.

• In Linux, if the Tomcat server is started with the security manager, FileI/O permissions will have to be speci�ed to allow �les from any directoryto be accessed by the application. To allow all permissions to the Ca-pability File Server application, place the �100CapaServer.policy� �le atthe location �/etc/{TOMCAT_HOME}/policy.d�. The �le contains thefollowing text that can be added manually if the �le is not available,

grant {permis s ion java . s e c u r i t y . Al lPermis s ion ;

} ;

A.2 Setting up SSL for Capability File Name Gen-eration

The Capability File Name Generation web application can be run without SSLif it is to be used locally or on a secure network. Otherwise it is recommendedthat SSL is set up on the web server. SSL capabilities can be set up on theApache Tomcat server using the following sequence of steps,

85

• Create a certi�cate keystore using the �keytool� utility that is part of theJava distribution.

# keytoo l −genkey −a l i a s tomcat −keya lg RSA−keypass change i t −s t o r epa s s change i t −keys to r e keys to r e . j k s

• Use the following command to export the generated certi�cate to a �le.

# keytoo l −export −a l i a s tomcat −s t o r epa s s change i t− f i l e s e r v e r . c e r −keys to r e keys to r e . j k s

• Create a truststore and add the certi�cate exported in the previous stepto it.

# keytoo l −import −v −t r u s t c a c e r t s −a l i a s tomcat− f i l e s e r v e r . c e r −keys to r e c a c e r t s . j k s −keypass change i t

• Finally, uncomment the "SSL HTTP/1.1 Connector" entry in {TOM-CAT_HOME}/conf/server.xml to enable SSL in Tomcat.

A.3 Setting up FUSE and the CapaFS Client Ap-plication

Following sequence of steps need to be followed to install the CapaFS clientapplication,

• Install the latest version of FUSE from [30].

• After unpacking the FUSE source archive, run the following commands inthe Linux terminal.

# . / con f i gu r e# make# make i n s t a l l

• Run the �install� script provided with the CapaFS application after un-packing the CapaFS client source archive.

• Run the CapaFS application using the command �capafs� on Linux ter-minal.

86

Appendix B

Code Listings

B.1 FUSE Low-Level Interface Operations

s t r u c t fuse_lowleve l_ops {

void (∗ i n i t ) ( void ∗userdata , s t r u c t fuse_conn_info ∗conn ) ;void (∗ dest roy ) ( void ∗ userdata ) ;void (∗ lookup ) ( fuse_req_t req , fuse_ino_t parent , const char ∗name ) ;void (∗ f o r g e t ) ( fuse_req_t req , fuse_ino_t ino , unsigned long nlookup ) ;void (∗ g e t a t t r ) ( fuse_req_t req , fuse_ino_t ino ,

s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;void (∗ s e t a t t r ) ( fuse_req_t req , fuse_ino_t ino , s t r u c t s t a t ∗ att r ,

i n t to_set , s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;void (∗ r e ad l i nk ) ( fuse_req_t req , fuse_ino_t ino ) ;void (∗mknod) ( fuse_req_t req , fuse_ino_t parent , const char ∗name ,

mode_t mode , dev_t rdev ) ;void (∗mkdir ) ( fuse_req_t req , fuse_ino_t parent , const char ∗name ,

mode_t mode ) ;void (∗ unl ink ) ( fuse_req_t req , fuse_ino_t parent , const char ∗name ) ;void (∗ rmdir ) ( fuse_req_t req , fuse_ino_t parent , const char ∗name ) ;void (∗ symlink ) ( fuse_req_t req , const char ∗ l i nk , fuse_ino_t parent ,

const char ∗name ) ;void (∗ rename ) ( fuse_req_t req , fuse_ino_t parent , const char ∗name ,

fuse_ino_t newparent , const char ∗newname ) ;void (∗ l i n k ) ( fuse_req_t req , fuse_ino_t ino , fuse_ino_t newparent ,

const char ∗newname ) ;void (∗ open ) ( fuse_req_t req , fuse_ino_t ino ,

s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;void (∗ read ) ( fuse_req_t req , fuse_ino_t ino , s i z e_t s i z e , o f f_t o f f ,

s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;void (∗ wr i t e ) ( fuse_req_t req , fuse_ino_t ino , const char ∗buf ,

s i z e_t s i z e , o f f_t o f f , s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;void (∗ f l u s h ) ( fuse_req_t req , fuse_ino_t ino ,

s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;

87

void (∗ r e l e a s e ) ( fuse_req_t req , fuse_ino_t ino ,s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;

void (∗ f sync ) ( fuse_req_t req , fuse_ino_t ino , i n t datasync ,s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;

void (∗ opendir ) ( fuse_req_t req , fuse_ino_t ino ,s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;

void (∗ r eadd i r ) ( fuse_req_t req , fuse_ino_t ino , s i z e_t s i z e , o f f_t o f f ,s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;

void (∗ r e l e a s e d i r ) ( fuse_req_t req , fuse_ino_t ino ,s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;

void (∗ f s y n cd i r ) ( fuse_req_t req , fuse_ino_t ino , i n t datasync ,s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;

void (∗ s t a t f s ) ( fuse_req_t req , fuse_ino_t ino ) ;void (∗ s e t x a t t r ) ( fuse_req_t req , fuse_ino_t ino , const char ∗name ,

const char ∗value , s i ze_t s i z e , i n t f l a g s ) ;void (∗ ge txa t t r ) ( fuse_req_t req , fuse_ino_t ino , const char ∗name ,

s i ze_t s i z e ) ;void (∗ l i s t x a t t r ) ( fuse_req_t req , fuse_ino_t ino , s i ze_t s i z e ) ;void (∗ removexattr ) ( fuse_req_t req , fuse_ino_t ino , const char ∗name ) ;void (∗ ac c e s s ) ( fuse_req_t req , fuse_ino_t ino , i n t mask ) ;void (∗ c r e a t e ) ( fuse_req_t req , fuse_ino_t parent , const char ∗name ,

mode_t mode , s t r u c t f u s e_ f i l e_ in f o ∗ f i ) ;void (∗ g e t l k ) ( fuse_req_t req , fuse_ino_t ino ,

s t r u c t f u s e_ f i l e_ in f o ∗ f i , s t r u c t f l o c k ∗ l o ck ) ;void (∗ s e t l k ) ( fuse_req_t req , fuse_ino_t ino ,

s t r u c t f u s e_ f i l e_ in f o ∗ f i ,s t r u c t f l o c k ∗ lock , i n t s l e e p ) ;

void (∗bmap) ( fuse_req_t req , fuse_ino_t ino , s i z e_t b l o ck s i z e ,uint64_t idx ) ;

void (∗ i o c t l ) ( fuse_req_t req , fuse_ino_t ino , i n t cmd , void ∗arg ,s t r u c t f u s e_ f i l e_ in f o ∗ f i , unsigned f l a g s ,const void ∗ in_buf , s i z e_t in_bufsz , s i z e_t out_bufsz ) ;

void (∗ po l l ) ( fuse_req_t req , fuse_ino_t ino , s t r u c t f u s e_ f i l e_ in f o ∗ f i ,s t r u c t fuse_po l lhand le ∗ph ) ;

} ;

88

Bibliography

[1] Kleinrock, L. �Information Flow in Large Communication Nets�. RLE Quar-terly Progress Report. July 1961

[2] Licklider, J.C.R., and Clark, W. �On-Line Man-Computer Communica-tion�. August 1962

[3] Roberts, L. �Multiple Computer Networks and Intercomputer Communica-tion�. In Proceedings of the ACM Gatlinburg Conference. October 1967

[4] Pfa�enberger, Bryan. �Computers in Your Future�. 1999

[5] Barry M. Leiner, Vinton G. Cerf, David D. Clark, Robert E.Kahn, Leonard Kleinrock, Daniel C. Lynch, Jon Postel, LarryG. Roberts, Stephen Wol�. �A Brief History of the Internet�.<http://www.isoc.org/internet/history/brief.shtml> (July 25, 2010)

[6] K. G. Co�man and A. M. Odlyzko. �Growth of the Internet�. AT&T Labs� Research. July 6, 2001

[7] Maurice J. Bach. �The Design of the Unix Operating System�. 1986

[8] Steve Best. �Linux Debugging and Performance Tuning: Tips and Tech-niques�. October 2005

[9] Steve D. Pate. �UNIX Filesystems: Evolution, Design, and Implementa-tion�. 2003

[10] Jude T. Regan and Christian D. Jensen. �Capability File Names: Sepa-rating Authorisation from User Management in an Internet File System�.2001

[11] Robin Anderson and Andy Johnston. �UNIX Unleashed�. 2002

[12] Arnold Robbins. �Unix in a Nutshell�. 1999

[13] Butler Lampson, Martín Abadi, Michael Burrows, and Edward Wobber.�Authentication in Distributed Systems: Theory and Practice�. 1992

[14] John H. Howard, Michael L. Kazar, Sherri G. Menees, David A. Nichols,M. Satyanarayanan, Robert N. Sidebotham, and Michael J. West. �Scaleand Performance in a Distributed File System�. 1988

89

[15] Microsoft. �[MS-SMB]: Server Message Block (SMB) Protocol Speci�ca-tion�. 2010

[16] W. Richard Stevens. �TCP/IP Illustrated, Volume 1�. 2002

[17] John H. Howard. �An Overview of the Andrew File System�. 1988

[18] Boris Bondarenko. �Comparison and Evaluation of NFSv3, NFSv4, andAFS Distributed Filesystems�. October 2001

[19] Steven M. French, IBM. �A New Network File System is Born: Comparisonof SMB2, CIFS and NFS�. 2007

[20] S.R. Kleiman, Sun Microsystems. �Vnodes: An Architecture for MultipleFile System Types in Sun UNIX�. 1986

[21] W. Richard Stevens and Jan-Simon Pendry. �Portals in 4.4BSD�. 1995

[22] Antti Kantee and Alistair Crooks. �ReFUSE: Userspace FUSE Reimple-mentation Using pu�s�. 2007

[23] Rajeev Nagar. �Windows NT File System Internals�. 1997

[24] David M. Ogle, Neil G. Sullivan and E. Hollins Williams, Jr. �PracticalExperience with OS/2 Installable File Systems�. 1992

[25] Frank Dabek, Emma Brunskill, M. Frans Kaashoek, David Karger RobertMorris, Ion Stoica, Hari Balakrishnan. �Building Peer-to-Peer SystemsWith Chord, a Distributed Lookup Service�. 2001

[26] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Bal-akrishnan. �Chord: A Scalable Peertopeer Lookup Service for Internet Ap-plications�. 2001

[27] Russel Sandberg. �The Sun Network Filesystem: Design, Implementationand Experience�. 1986

[28] Mary G. Baker, John H. Hartmart, Michael D, Kupfer, Ken W. Shirri�,and John K. Ousterhout. �Measurements of a Distributed File System�.1991

[29] David Mazi`eres, Michael Kaminsky, M. Frans Kaashoek, and EmmettWitchel. �Separating key management from �le system security�. 1999

[30] �Filesystem in Userspace�. <http://fuse.sourceforge.net/> (July 25, 2010)

[31] Apache. �SSL Con�guration HOW-TO�.<http://tomcat.apache.org/tomcat-5.5-doc/printer/ssl-howto.html>(July 25, 2010)

[32] Sun. �Sun Java System Application Server Platform Edition 9Administration Guide�. <http://docs.sun.com/app/docs/doc/819-3658/ablrb?l=en&a=view> (July 25, 2010)

[33] Olivier Dalle. �MPCFS : a virtual FileSystem for MultiPoint Communi-cations�. <http://www-sop.inria.fr/members/Olivier.Dalle/mpcfs/> (July25, 2010)

90

[34] �Application Layer ISO OSI Functionality and Protocols�.<http://www.highteck.net/EN/Application/Application_Layer_Functionality_and_Protocols.html>(July 25, 2010)

[35] Elizabeth D. Zwicky, Simon Cooper and D. Brent Chapman. �BuildingInternet Firewalls�. Ch.17. June 2000

91