extract file system type from es_event_mount_t

Hello,

es_event_mount_t includes statfs structure. This structure has the field 'f_type' which defines type of filesystem. However, man page says nothing about possible values of this field.

What is the best way to define file system type? Can I use 'f_type' or 'f_fstypename'? If so, are there any constants in header files which can be used?

Thank you for your help!

Answered by DTS Engineer in 824988022

es_event_mount_t includes statfs structure. This structure has the field 'f_type' which defines type of filesystem. However, man page says nothing about possible values of this field.

Yes, and the short summary is that the value of "f_type" isn't something that will be all that useful to you (which is what it isn't defined).

What is the best way to define file system type? Can I use 'f_type'

No.

or 'f_fstypename'?

What are you actually trying to do? If you're you're purely collecting a value for display/informational purposes, then sure, you can copy that value. However:

If so, are there any constants in header files which can be used?

...if you're trying to base programmatic decisions on "file system type", well, that doesn't really work. There are there are a two critical issues with that approach:

  1. The value isn't stable. You can add new files systems to the system, which means the fields value isn't predictable.

  2. The characteristics of a given file system are FAR more variable than most developers expect. As the most direct example, smb shares typically "present" themselves as having the same capabilities (or less) of their parent file system, which means they can basically present as the same configuration "range" as basic FAT all the way to case sensitive APFS.

The preferred approach here is to look for the capabilities you're interested in, typically through "getattrlist". That won't be an option prior to mount, but it's the better approach if you're trying to gather information post-mount.

Finally, returning to this point:

es_event_mount_t includes statfs structure.

My recommendation is that you use DiskArbitration as your primary mechanism for blocking mounts. This post and this post have more details about why that's the case, but the quick summary is:

  1. You'll have access to more information than ES provides.

  2. You won't have the same level of time pressure that ES does.

  3. The system "expects" DiskArb to block mounts, so it handles those failures relatively gracefully.

You'll still use es_event_mount_t as the "final" protection system, but it's role will be to immediately approve mounts you've already preflighted with DiskArb and block edge cases where DiskArb is specifically being bypassed.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Accepted Answer

es_event_mount_t includes statfs structure. This structure has the field 'f_type' which defines type of filesystem. However, man page says nothing about possible values of this field.

Yes, and the short summary is that the value of "f_type" isn't something that will be all that useful to you (which is what it isn't defined).

What is the best way to define file system type? Can I use 'f_type'

No.

or 'f_fstypename'?

What are you actually trying to do? If you're you're purely collecting a value for display/informational purposes, then sure, you can copy that value. However:

If so, are there any constants in header files which can be used?

...if you're trying to base programmatic decisions on "file system type", well, that doesn't really work. There are there are a two critical issues with that approach:

  1. The value isn't stable. You can add new files systems to the system, which means the fields value isn't predictable.

  2. The characteristics of a given file system are FAR more variable than most developers expect. As the most direct example, smb shares typically "present" themselves as having the same capabilities (or less) of their parent file system, which means they can basically present as the same configuration "range" as basic FAT all the way to case sensitive APFS.

The preferred approach here is to look for the capabilities you're interested in, typically through "getattrlist". That won't be an option prior to mount, but it's the better approach if you're trying to gather information post-mount.

Finally, returning to this point:

es_event_mount_t includes statfs structure.

My recommendation is that you use DiskArbitration as your primary mechanism for blocking mounts. This post and this post have more details about why that's the case, but the quick summary is:

  1. You'll have access to more information than ES provides.

  2. You won't have the same level of time pressure that ES does.

  3. The system "expects" DiskArb to block mounts, so it handles those failures relatively gracefully.

You'll still use es_event_mount_t as the "final" protection system, but it's role will be to immediately approve mounts you've already preflighted with DiskArb and block edge cases where DiskArb is specifically being bypassed.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you for response!

Looks like the only way of getting fs type is to analyse string values. (kDADiskDescriptionVolumeKindKey is string too)

What are you actually trying to do?

Monitoring new mounts but first of all app must enumerate mounted volumes. I am enumerate all mounts by getmntinfo_r_np() and it returns devfs which must be skipped.

Looks like the only way of getting fs type

Yes, but that are you actually trying to learn from that? The issue with a lot of this information it's that it's accuracy often depends on the vary components you're trying to validate. Case in point, if you're goal is to separate "safe" volume formats (say, HFS+ or APFS) from "unsafe" (other stuff), then the issue here:

is to analyse string values. (kDADiskDescriptionVolumeKindKey is string too)

Is that the string came DIRECTLY from the VFS driver you're concerned about. In other words, that string value doesn't mean "this volume is <blah>" but actually means "the VFS driver said it's <blah>". That's fairly trustworthy if you know exactly what VFS drivers are on the system... and not at all trustworthy if you don't. That means that what you're using the data for matters more than the data itself. Case in point:

Monitoring new mounts but first of all app must enumerate mounted volumes. I am enumerate all mounts by getmntinfo_r_np() and it returns devfs which must be skipped.

It's totally reasonable for you to:

  1. Immediately ignore a single devfs (f_fstypename) mount at "/dev/" (f_mntonname). I think you could even go further and simply ignore exactly one mount at "/dev/".

  2. Look very closely at any additional devfs mount anywhere else.

  3. Look very closely at any "extra" mount at /dev/ (or any child path).

The first case is the "base" behavior of the current system and any divergence from it represents a deeply weird divergence. However, the reason you can trust the data here isn't that the data itself is "inherently" trustworthy- indeed, I think you probably good make a VFS driver that presented itself as "devfs". However, what you can't do is prevent the system from doing this initial mount at "/dev/" or force the system to later unmount it.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you for the help!

extract file system type from es_event_mount_t
 
 
Q