Download File systems in Windows

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Data vault modeling wikipedia , lookup

Object storage wikipedia , lookup

Asynchronous I/O wikipedia , lookup

Lustre (file system) wikipedia , lookup

File system wikipedia , lookup

Disk formatting wikipedia , lookup

Design of the FAT file system wikipedia , lookup

XFS wikipedia , lookup

File Allocation Table wikipedia , lookup

Computer file wikipedia , lookup

File locking wikipedia , lookup

Files-11 wikipedia , lookup

Transcript
CE01000-3
Operating Systems
Lecture 18
Windows – NT File
System (NTFS)
Overview of lecture

In this lecture we will look at:


NT File System (NTFS)
Encrypting File System (EFS)
Windows structure overview
USER APPLICATION
SUBSYSTEM DLL
SYSTEM
SUPPORT
ENVIRONMENT SUBSYSTEM
NTDLL.DLL
USER MODE
KERNEL MODE
EXECUTIVE
API
I/O
MANAGER
CACHE
MANAGER
PROCESS &
THREAD
MANAGER
SECURITY
REFERENCE
MONITOR
FILE
SYSTEMS
PLUG & PLAY
MANAGER
POWER
MANAGER
CONFIGUARI
ON
MANAGER
OBJECT
MANAGER /
LOCAL
PROCEDURE
CALL
DEVICE
DRIVERS
HARDWARE
VIRTUAL
MEMORY
MANAGER
Graphics drivers
KERNEL
ABSTRACTION
Win32 USER and
GDI (Graphics
engine)
LAYER
(HAL)
SYSTEM
SERVICES
File systems in Windows




in Windows the file system is part of the I/O
system.
the I/O manager provides device
independent I/O facilities, in our case
Either the file manipulation facilities that are
independent of the hardware of the physical
device the file data is stored on
or the type of the file system that is used to
organise the way the file data is held on the
physical device.
File systems in Windows
(Cont.)


to achieve this the software that controls the
physical hardware and any file systems
must be separate from the I/O manager
physical devices which hold file data e.g.
disks, DVDs, pen drives, etc. will have
device drivers that form part of the I/O
system
File systems in Windows
(Cont.)


the file system is implemented by a file
system driver - in this case the file system
driver will use the backing store device
drivers when it wishes to access the
physical devices.
Windows processes can access files from
different file systems provided an
appropriate file system driver exists e.g.
Dos FAT file system, NT File System, Posix
(Unix) file system, etc.
Representation of files in
Windows


files in Windows are considered objects i.e.
they are resources for which the object
manager holds a representation that is an
object
a process that is accessing a file will have a
file handle (as a data structure or an object,
depending upon the language of the
processes source code)
Representation of files
in Windows



the file handle will contain an index into the
object handle table
the object handle contains the reference to
file object
the file object contains a set of attributes and
services
Representation of files in
Windows
Process
File
handle
Object handle
table
File object
File system
specific
data
structures
Representation of files
in Windows (Cont.)



the attributes include file name, but also info
on current location in file for next read/write
operation, type of device file resides on, etc.
the services include file creation, deletion,
read, write, get file info, set file info, etc.
file object also contains a reference to file
system specific data structures that provide
the mapping between the logical file object
and the physical file data on the hardware
device e.g. disk
Layered file system driver and disk
device driver
Environment subsystem or DLL
User mode
1
Kernel mode
Executive API
2
File system
driver
3
4
Device driver
5
disk
I/O
manager
writing to disk via file system
driver and disk driver
1. write data at specified byte offset within file
2. translate file-relative byte offset into disk relative
byte offset and call next driver
3. call driver to write data at disk relative byte offset
4. translate disk relative byte offset into physical
location
5. transfer data
Files, sectors, and clusters
- reminder


File data is held on disk is broken up into
smaller units. Smallest unit of data on disk is
the data held by 1 physically formatted sector
(segment of a track) - often 512 bytes in size
(but this can be Operating System specific).
NTFS organise disk manipulation in terms of a
consecutive sequence of sectors on a disk
called a cluster (this is not true of all Operating
Systems)
Files, sectors, and clusters
(Cont.)


File data is held on disk in 1 or more clusters.
These clusters may not be consecutive but
may be spread all over the disk.
The problem for the file system is to be able
to retrieve the sequence of file data from
these scattered locations
Clusters and files reminder
Sectors



sector = formatted
segment of track typically
512 bytes per sector
Cluster is sequence of
sectors (often 4/8 sectors
depending on disk size)
File is sequence of
clusters (not necessarily
consecutive)
Logical Cluster Numbers




NTFS refers to disk locations via a Logical
Cluster Number (LCN)
numbers are assigned to all clusters in
disk volume from 0 to N (number of
clusters in volume - 1)
this number is LCN
these LCNs are mapped onto physical
cluster locations by storage media device
driver
Virtual Cluster Numbers




NTFS refers to locations within a file by a
Virtual Cluster Number (VCN)
numbers are assigned to all clusters that
make up the file from 0 (file start) to M
(number of clusters in file - 1)
the clusters that make up the file may not be
contiguous
NTFS maps from VCN for a file onto LCN
Indexing of blocks in NTFS




NTFS locates files on disks using index blocks
(Unix uses a similar index block method)
File object contains a reference to File Control
Block (1 per file) and this in turn contains a file
reference number
file reference numbers identify a record (by
providing an index) in the Master File Table
Master File Table (MFT) is a file of file records with usually 1 record per file in the file system
Master File Table (Cont.)
Process
File
handle
object handle
table
File object
File
control
block
Master File
Table
Master File Table (Cont.)

Record in Master File Table (MFT) contains:




standard file information such as time stamps,
whether read-only, etc.
Filename
security descriptor - file ownership and access
permissions
file data attribute field (for data files) or file
indexing attribute field (for directories)

data is treated as just another attribute of a file
Master File Table (Cont.)

For very small files data is actually contained
in data attribute field of MFT record
SMALL FILE
file info
file name
security
info
DATA
Master File Table (Cont.)
LARGE FILE
file info
file name
security
info
file data run
references
VCN 2
VCN 0
LCN 134
DATA
DATA
LCN 213
VCN 1
LCN 135
DATA
Master File Table (Cont.)



For larger files (most files) data attribute field
contains a series of references to file data runs
a file data run is a cluster that contains the
actual file data
For even larger files the MFT record will
contain a reference to another MFT record
entry that contains further file data run
references in its data attribute field i.e. the MFT
records can become chained together to
represent massive files
Directory file indexes




in NTFS directories are represented by
entries in MFT
MFT contains an entry for the root directory
of the NTFS file system volume
for directories files are identified by file
indexes
file indexes contain file reference numbers
(effectively an index into MFT), plus file
name, time stamp info and file size for file
Directories


in a directory record in MFT then instead of
data attribute field there are indexing
attribute fields
For small directories files within directory
are identified by a series of file indexes held
in indexing attribute field
SMALL DIRECTORY
file info
file name
security
info
file-index1....
file-indexN
Directories (Cont.)
LARGE DIRECTORY
file info
file name
security
info
file index buffer
references
file-index1....
file-indexN
file-indexN+M+1....
file-indexZ
file-indexN+1....
file-indexN+M
Directories (Cont.)


For larger directories indexing attribute field
contains a series of references to file index
buffers
a file index buffer is a cluster that contains
the series of file indexes for the files within
that directory
Encryption – simple
explanation




Encryption is a mechanism by which you can transform
the content of a file into something that appears
meaningless by applying an algorithm to change the
data (decryption restores original meaningful file
content)
The precise way in which the data is changed can be
made to depend upon a key value (which is a
parameter to the encryption algorithm)
if the encryption algorithm is a good one you can only
decrypt the file (get the original content back) if you
have the key.
Hence important to have a key that is kept secure and is
hard to guess
Encrypting File System



To provide additional levels of security the NTFS
provides an encryption & decryption service
known as the Encrypting File System (EFS)
Using this a user can encrypt/decrypt specific
individual files or whole directories (and subdirectories)
EFS was a separate file system driver in
Windows 2000, but in XP onwards has been
integrated into NTFS itself
Encryption process



When encrypting a file Windows generates a
random key FEK (File Encryption Key)
Windows uses an industry standard
encryption algorithm AES (Advanced
Encryption Standard) or 3DES (Triple Data
Encryption Standard)
These are symmetric key encryption
algorithms that are suitable for encrypting
large amounts of data
Encryption keys



Windows stores the FEK as part of the file it
has encrypted – so how to stop someone
decrypting the file by using the FEK that is
held as part of the file?
Windows encrypts the FEK itself using RSA
an asymmetric key algorithm – these are only
suitable for encrypting small amounts of data
(which the FEK is)
RSA uses a public key in its encryption/and a
separate private key in decryption
Encryption keys (Cont.)



Anyone who has the private key can decrypt
the FEK – so Windows needs to keep that
private key safe
Windows stores the private key that is used
for decryption in a subdirectory of the user
profile directory and encrypts all the keys
and files in that subdirectory using a
AES/3DES using a master key
But how do we keep the master key safe?
Encryption keys (Cont.)


Master key is also stored with the user profile
information and encrypted in turn by a key
that is based on the user password
This key is constructed at logon and held in
the OS address space (i.e. in main memory)
– ready to be used – but not written to the
disk
Encryption keys (Cont.)


Problem is – master key is only as good as
the user password i.e. you might be able to
guess the password (based on information
you know about the person) or try out
different keys (a key search) but rather than
trying all possible keys (takes too long) you
try likely keys (based on likely passwords,
e.g. dictionary words/names, etc)
So maybe not as secure as it seems
References

Operating System Concepts. Chapter 22.