- [Instructor] On a Linux system,
we interact with file system metadata in a few ways.
To explore basic attributes of a file,
we can use the stat command.
Here we see the permissions,
the various timestamps associated with the file
and some other information
like the owner and group IDs,
the inode for the file
and its size and how many blocks
on the file system the file occupies.
None of these values are the actual data of the file.
They're all metadata stored in the file system
associated with the blocks or extents
where the file's actual data is kept.
We'll explore some of these other fields here shortly,
but first, I'd like to draw your attention
to these timestamps here.
There's space for four of them,
but usually only three are used
because those are the three that POSIX requires.
These three are called the access time or A time,
the modify time or M time
and the change time or C time.
Access time is when the file was last accessed or read.
Modify time is when the files contents were last modified.
And change time,
while it sounds similar to modify time,
is when the files inode information was changed.
So for example,
if we change the files permissions or name
or something that's associated with the inode,
that will affect the C time or change time.
If we open the file in an editor,
modified its contents and saved the file,
that would affect the M time
or modification time.
These values are updated by the system
when their associated change occurs,
but we can also use the touch command
to change the values too.
I won't spend a lot of time on this here,
but let's take a look at this file from before.
Using the touch command and a D option
followed by a date time string and the file name,
I can change both the access
and modification times for this file.
We can see that change with stat myfile1 again,
and there we go.
Take some time to explore the manual page
for the touch command
for some more useful options
including the -r option,
which can read the times from one file
and apply them to another.
This display shows the permissions
and also shows the modified time for each file
and we see its name and size.
We can use the -lc option
and the -lu option
to show change time
and access time respectively.
This number here refers to how many links there are
to the files inode.
Most files will have just one,
representing the file we see,
but if there are symbolic links
or hard links pointing to the files inode,
the number will increase.
File permissions tell the system
which users and groups can read,
write and execute a file.
Permissions are extremely important on Linux systems,
but because this isn't a Linux course,
we won't be getting into the details of them here.
We'll just take a look
from a metadata perspective in this video.
We can modify a file's access permissions
with the chmod command,
followed by either
a numeric representation of the permissions
like 755, or a symbolic representation
using plus, minus or equals
and various letters to represent permission modes.
And we can change the file ownership
or file group with chown and chgrp.
File access permissions are a fairly basic
and widely supported attribute
across many UNIX type file systems,
but there is one important factor to keep in mind
when we copy files that have permissions.
Permissions are represented
by user and group numeric IDs,
not explicit user and group names.
In most cases,
a user copying their own files
to another disc or system
will result in behavior we expect,
correctly setting the owner and group ID,
but if we copy files using other tools
that preserve these owner and group ID values,
we might have unexpected results on the target system.
For example, on one system,
the user Mary, might be the owner of a file
and have the user ID 1004.
If we copy that file to another system,
depending on how that copy operation is performed,
we could end up with that same file showing ownership
by whatever user account corresponds with 1004
on the other system.
Or if there isn't a user ID 1004,
we would just see the number 1004.
We can fix this with permissions management tools,
but this highlights the fact
that permissions on a file
aren't a reliable indicator of a person or user
actually being responsible for that file.
Permissions can be changed easily
by administrative users
and are often ignored in the copy process,
especially between platforms.
While they are represented by file system metadata,
file permissions aren't the focus of this course.
If you'd like to learn more about them though,
take a look at my course
called "Learning Linux Command Line"
or other courses about Linux basics
here on LinkedIn Learning.
Other metadata that Linux type file systems store
include ACLs or access control lists.
ACLs allow us to be more specific
about who can do what with files.
For example,
we can set up a much richer
and more complex set of rules
about who can do what
to which files on a given system.
On a Linux system,
the file system itself needs to be mounted
with support for ACLs
in order for us to set ACLs
because that particular metadata structure
needs to be in place.
So not all Linux systems will have ACLs by default.
Here in the terminal,
I'm using an external volume.
It's EXT4,
which means it automatically includes ACL support.
Using the LS command with the -l option,
we can see whether a file has an ACL.
Here I can see one file has a plus
after the regular permission string
and that indicates that it has an ACL.
We can see which ACLs are applied to files
with the command getfacl or get Facl,
facl being short for file access control list.
Here we can see an ACL
that grants a group called accounting
read, write and execute access to the file.
Notice in this output
that there's another indication for others,
which from the perspective of this file,
is what any member of the accounting group would be.
This would deny the accounting group
write and execute access.
This is overridden by the ACL,
which specifically grants this group full access,
even though the system will deny write
and execute access to any other group member.
To modify an ACL,
we can use setfacl and the -m option,
followed by an access control entry.
For example,
we can change the existing entry
to only allow this group read access.
I'll write setfacl -m g:
and the group name :r for read
and then the file name.
Again, I'll run getfacl,
and we can see that change was made.
Access controls with ACLs are an important part
of security on Linux systems
and they're part of the file system metadata.
In addition to basic attributes like permissions,
dates and so on,
files on most Linux systems can have extended attributes
which are further ways to tag information
onto files on the system.
They're represented by key value pairs.
To read extended attributes on files,
we can use the getfattr command
and we can set values with setfattr.
On modern Linux compatible file systems
like EXT4,
we can set user extended attributes on a file,
allowing us to add any text-based key name we want
and any text, hexadecimal
or base 64 encoded value associated with it.
Some applications use this feature
to add their own tags or other metadata
to files they work with.
Older Linux compatible file systems may need
to be specifically mounted
with user extended attribute support
and others don't support extended attributes at all.
We can add an extended attribute with setfattr
and the name and the value followed by the file name.
I'll write setfattr -n,
user. and the name of my attribute.
Then -v and a value,
and then I'll provide a file name.
Now let's use getfattr -d and an asterisk
to view the extended attributes
for all the files in this directory.
Only one file has them,
and here's the value that I set for this file.
Extended attributes can contain some interesting information
so they can be a vector
for inadvertently sharing information
that might not be meant to be shared.
As long as a volume is mounted
with extended attribute support,
these attributes will be available.
But if files with extended attributes
are copied to a file system that doesn't support them,
the attributes will be removed
and these values will be removed
if the file is moved or copied by tools
without extended attribute support.
Spend some time with the setfattr manual page
to learn more about how extended attributes work.
While extended attributes allow us
to set key value pairs of information on files,
there's another kind of information
we can add to files called flags.
These are simple on/off setting names
and functions defined by the file system.
Some of these flags can be used
to make a file undeletable,
to mark it so that the access time isn't updated and more.
To work with these values,
we'll use the commands lsattr and chattr.
The manual pages for the chattr command
briefly list the available flags
and I encourage you to explore that.
We can set flags with the chattr command
followed by an option like +i
to add the immutable flag to a file.
Now, even though I'm the owner of that file,
as I can see here,
I'll be unable to delete it
without first removing the flag.
Even the super user can't delete this file directly.
We can take a look at the flags
for files in this directory
with lsattr and an asterisk.
Here we see the individual flags in a compact view.
E means extents,
indicating that this file uses extents,
which we would expect,
given that this is an EXT4 file system
which uses extents rather than blocks.
The more interesting flag here is I,
which represents immutable,
and we can see that more in detail
with lsattr, -l for list,
and the file name,
which lists the name
instead of just the letter for each flag.
While flags don't necessarily reveal
a whole lot of information about a file,
they can be indicators that a file is interesting.
A different file state
that the system administrator wants to enforce after all,
points to that file being different
than the files around it.
And it's good to know about these flags
if we're working on a file
that doesn't respond in the way we think it might.
Perhaps it's marked as immutable
or has no A time updates and so on.
As with other metadata values,
this flag will copy to other supported file systems
when using tools that are aware of flags
but will be dropped
when copied to unsupported file systems.
Some Linux file systems
use an access management solution
called SE Linux
to further refine how files can be used.
This information is also stored as extended attributes
in the security name space
on supported file systems.
On a system that uses SE Linux,
we can find this information for files
by using the command ls -Z to show the context,
which is what SE Linux calls
the access control information it applies to
and reads from files.
As we'll see throughout the rest of the course,
the basic file system metadata values
like file name and access and modification times
will transfer pretty easily
to other file systems.
Permissions can transfer
but lose a lot of context and meaning,
even when they're preserved.
And extended metadata values can't be set
on all file systems
and don't always transfer to other file systems,
but sometimes they do,
as we'll see a bit later.
Unfortunately,
there isn't a whole lot of specific documentation
about which combinations of file systems,
tools, and attributes
can transfer these values successfully.
Some individual research is needed
when setting up a system where these are used.
ACLs are really intended for use within one system
or within one administrator controlled network of systems.
They won't protect files copied to other systems,
much less other file systems or operating systems.
If you're working with security on Linux,
it's important to understand
how metadata affects security
and how it can fail us if we're not careful.
It's also important to keep in mind
what information is exposed by this metadata
and how that could be a security risk.
For more Linux specific detail about ACLs
and other topics we're exploring here,
take a look at the course "Linux: Files and Permissions"
here on LinkedIn Learning.