- [Instructor] Macs typically use
either the HFS+ or APFS file systems,
and these file systems
can both store metadata about files,
like permissions
and extended attributes.
Macs also use other strategies
to store platform specific metadata
and to represent file metadata on systems
that don't have metadata support.
macOS is derived in part from FreeBSD,
so it's Unix heritage gives it
a similar approach
to most Linux file systems
when it comes to file metadata.
Standard UNIX permissions
for the file owner,
the owning group,
and others are represented,
and the macOS file systems
also include access control lists,
extended attributes,
and flags.
The file system also stores
a files last access time,
modification time,
change time,
and birth or creation time.
We can view many aspects
of a file's metadata in the finder
using the info pane,
which we can open by selecting a file
and then pressing Command + I.
This lists a variety
of regular attributes
and some extended attributes
we'll explore shortly.
Using command line tools,
we can explore the file system metadata as well.
Some of the command line tools we'd use
for this on a Mac
are the same as on Linux,
including stat,
to show a general overview
of the file metadata.
Or stat -x to show us
an output more similar to the Linux version.
We can use ls -l to see most
of this information listed out
for files in a directory.
We can use chmod to set permission modes
with octal or symbolic notation,
and we can use chown and chgroup
to change a files owner and group.
Access control lists,
usually called ACLs for short,
are a set of enhanced permissions
we can apply to files and folders.
Access control lists,
usually called ACLs for short,
are a set of enhanced permissions
we can apply to files and folders.
macOS file systems support ACLs by default
and don't have to be remounted
to support them,
unlike some older Linux file systems.
We can see whether a file or folder
has an ACL applied to it
with the ls -l command.
Entries with a plus after
the permission string have an ACL,
and that could be simply
one access control entry or ACE,
or it could be more,
ACLs are lists after all.
One trick here though,
is that the plus sign indicating
an ACL can get covered up in the output
by an @ sign,
which is something
we'll explore in just a moment,
so it's usually more useful
to simply use ls in a way that
shows the ACL of each item,
like ls -le.
Notice that these entries have
a plus sign and an ACL,
but this also has an ACL,
indicated by the description below it,
but it doesn't show a plus in the column.
The plus is getting superseded
by the @ sign,
but we can still see the entries
in each item's ACL.
This entry here, for example,
is targeted toward the group called everyone,
which includes all users,
and it specifically says
that members of that group
may not delete this item.
The superuser still can,
but even the owner of
this item can't delete it
without authenticating his root.
This is common on macOS
to prevent users
from accidentally tearing apart things
the system relies on,
and leaving it in an unbootable
or unexpected state.
Because this course isn't focused
on access control in particular,
I won't go into a lot of detail
about setting and modifying ACLs.
That's a topic for another course,
but here's the basics.
On a Mac,
we'll use chmod
and the +a option to set an ACL.
We'll follow that
with the access control entry,
and the name of the file
whose ACL we want to add to.
I'll write chmod +a,
and then in double quotes,
user2 deny read,write
and then my file name.
I'll take a look at the entries
with ls -le,
and here we can see the entry.
We can move this entry,
which is number 0 with chmod -a
and the pound sign,
then the number for that entry, 0,
and the file name to modify.
We could also use the index notation
to insert entries at other points
in a longer list as well.
We can remove all ACLs
from a file with chmod -N.
Generally, ACLs will transfer
with their files to other Macs,
but won't carry across
to other operating systems
and may be stripped when files are copied
to non Mac file systems,
so they shouldn't be relied on
to secure files outside
of a managed macOS environment.
If you need to work with ACLs on Macs,
be sure to spend some time
with the manual page for chmod,
in the section ACL Manipulation Options.
Like on Linux systems,
Macs have a variety of extended attributes
we can set on files.
The operating system uses these extensively
for things like file quarantine
and system integrity protection.
There are also system defined attributes
like a field called ItemWhereFroms,
which lists the source of a file
and so on.
There's no specific list of these,
because while a system uses
and offers many attributes,
we can also define our own,
which is useful if for a software developer
or something like that,
so it's worth taking time
to explore on your own
and see what attributes exist
on files you come across.
If we run a long listing
of files in a directory
with ls -l,
we can see that some items have an @ sign
to the right of the permission string,
this indicates that a file
has extended attributes.
To further investigate these,
we can use the xattr command,
short for extended attributes,
followed by a file name
or list of files.
Extended attributes are entries
in a key value database,
so the names we see here function as keys
and the each have
an associated value.
Here we see the keys of a given name,
which tells us that
the particular extended attribute
has been applied to the file.
To view the value of each key,
we can use xattr -l
and the file name,
and here I can see that this items
kMDItemWhereFroms lists
the website download-installer.cdn.mozilla.net
as the source of the file.
This is a Firefox installer
that I downloaded earlier.
This value here was set by the browser
and other software
will often set extended attributes
that specifically to it.
The value here is a binary plist,
but we can still read it pretty well.
Downloaded files will also often have
a quarantine tag added to them,
indicating that they
might need to be scanned
by the system's malware scanner.
One interesting item in the quarantine tag
is the browser used to download the file.
I'll switch over to my finder
and select a file.
I'll right click on It
and I'll highlight it blue.
Then I'll open up its information
and add a comment.
Back here in the terminal,
I can see this file now has extended attributes,
and if I take a look at them,
I can see that information here.
For example,
the item user tags refers to blue,
the color we set for the highlight,
and the item called ItemFinderComment contains
the comment that I set for the file.
As we'll see later,
these fields can be used
for spotlight search.
While this additional information
attached to the file can be useful,
it can also be a security risk.
For example,
if you downloaded a file
from a personal shared cloud link,
a username or even an access token
might be present in its URL.
Other fields could also reveal information
of various types,
and those values will persist
if the file is copied
to another HFS+ or APFS volume.
Those values can persist
on other file systems too,
as we'll explore shortly.
Luckily, because these values
are metadata stored in the file system,
we can modify them.
And the command xattr -w followed by a key
and a value, and the file name,
will write a specified key
and value for an attribute.
While we can set text values like this
from the command line,
other values like the color highlight
and things that need to be binary plists
take a little bit more work
to add in the terminal.
If you're working
with this kind of information on a Mac,
be sure to check out the manual page
for xattr with man xattr,
for more details about this really useful command.
And recognize that we can set some
of these extended attributes
from the GUI as well as we've seen.
While extended attributes
let us set key value pairs
for arbitrary data,
flags are single characteristics
that we can apply to files.
For example,
one commonly used flag is called hidden,
and it makes finder not show
a specific file or directory,
unless the view mode is switched
to show all files.
Customarily on Linux and Mac systems,
adding a dot or period
to the front of a file name
will mark it as hidden
when files are listed in the finder
or in the terminal,
but it's not always practical
to change the name of a file
simply to hide it from casual observers.
In fact, on macOS,
the user's library folder
in their home folder,
has this special hidden flag applied to it,
to gently conceal it
from users who might not know
what it's for.
In the terminal,
we can see which files
in a folder have flags
using ls -lO.
For example,
here in my user folder,
I can see in this column
that the -O option
brings in that my user's library folder,
in fact has that hidden flag applied.
Let's leave this directory alone though,
and work on some other files instead.
I'll resize my terminal here a bit
and bring my finder window over
to the side.
We can apply a flag to a file
with chflags,
and the flag we want to use
in this case hidden
and the file name to apply that flag to.
I'll write this out over here
in the terminal,
but keep an eye on finder over here
when I run that.
Ta-da,
the file is hidden,
but we can still see it with the terminal,
and we can reveal it
with Command + Shift + . in the finder.
There it is, sneaky.
We can see that that file has
that flag applied again
with ls -lO.
Here's the hidden flag,
and we can remove a specific flag
with chflags
and the flag with the word no
in front of it like this.
I'll write, chflags nohidden myfile1.
And there it's back to normal.
While the hidden flag
is probably the easiest to demonstrate
because it makes the file disappear,
some flags are used
by system administrators
to control how users
can interact with files.
From a security perspective,
these are a bit less information dense
than other attributes,
but they can still be important
to know about.
Again, be sure to look at
the man chflags manual page
to explore the available flags.
Regular attributes,
extended attributes,
ACLs and flags are all aspects
of the file system metadata on a Mac,
and one of the reasons
a lot of Mac software is
distributed disk image files,
is to preserve these metadata values,
which are or were often stripped
by tools like ZIP and tar.