Make filesystem type configurable for periodic(8)?

Andriy Gapon avg at FreeBSD.org
Fri May 4 21:25:35 UTC 2012


on 04/05/2012 19:08 Bryan Drewery said the following:
> On 05/04/2012 11:05 AM, Freddie Cash wrote:
>> A few of the periodic(8) scripts in FreeBSD have constructs similar to
>> the following to get which filesystems to scan for various things:
>>     MP=`mount -t ufs,zfs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`
>>
>> For systems with large ZFS pools, and many ZFS filesystems, these
>> periodic scripts can grind it to its knees, and then some.  For
>> backups servers where we don't really care about the
>> ownership/permissions of files from the FreeBSD perspective, we really
>> don't want the ZFS filesytems to be scanned; only the UFS ones for the
>> FreeBSD OS install.  To that end, I have to manually edit these files
>> to remove the ",zfs":
>>     MP=`mount -t ufs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`
>>                           ^^^^^^^^
>> Would it be worthwhile to anyone else to make the filesystem type(s)
>> to scan via the periodic(8) scripts a variable that's set by default
>> in /etc/defaults/periodic.conf and that user's can override via
>> /etc/periodic.conf?
>>
>> Or, am I the only one that's suffering here?  :)
>>
>> If there's interesting in this, I can look into coming up with some
>> patches.  But wanted to check if anyone else would find it useful.
>>
> 
> I would find this useful. But further, I have a ZFS root pool as well as
> a ZFS backup pool. I don't want to exclude all of ZFS, just certain
> pools, or even certain datasets.

Guys,

why do you think that FS type is significant for these periodic security checks?
Why ZFS (or some other FS) must be immune to a rogue suid script or some other
permissions-based security threat?
If you are sure that your ZFS datasets can not be a source of such an attack,
then why not:
1) either disable the periodic security check altogether?
2) or mark the appropriate datasets as noexec or nosuid to ensure your belief?

-- 
Andriy Gapon


More information about the freebsd-stable mailing list