linux-ext4 - Re: [REPOST][PATCH][RFC] vfs: add message print mechanism for the mount/umount into the VFS layer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100115012421.GA28498@discord.disaster>
Date:	Fri, 15 Jan 2010 12:24:21 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Andreas Dilger <adilger@....com>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Toshiyuki Okajima <toshi.okajima@...fujitsu.com>,
	tytso@....edu, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: [REPOST][PATCH][RFC] vfs: add message print mechanism for the
	mount/umount into the VFS layer

On Thu, Jan 14, 2010 at 10:33:42AM -0500, Andreas Dilger wrote:
> On 2010-01-14, at 03:14, Al Viro wrote:
>> I am not going to apply that.  For one thing, printk is improper  
>> mechanism
>> for "observing [normal] operations".  Vague references to "enterprise
>> users" wanting that do not constitute a valid rationale.
>>
>> What's more, there is absolutely no point in taking care to have  
>> mount(2)
>> spew something in log when explicitly asked to do so; caller can  
>> bloody
>> well do it itself.  From userland.
>
> Sure, it is _possible_ to do this, but you miss the fact that there are 
> many system monitoring tools that already scrape /var/log/messages and 
> integrate with event managers.  What you are suggesting is that every 
> such tool implement an extra, completely ad-hoc mechanism just for 
> monitoring the mount/unmount of filesystems on Linux.  That doesn't make 
> sense.

We already report various events through a netlink interface, but not
to the log files (e.g. quota warnings), so those system monitoring
tools are already going to be missing interesting information.

Using log files for system event notification used to be the only
way to communicate such events. Now we have much more advanced and
efficient mechanisms for notifications so I think we should use
them.

FWIW, having a general event channel for reporting filesystem events like
mount, enospc, corruption, etc makes a lot of sense to me.
Especially from the point of view that they can be also be tied into
automated filesystem test harnesses easily....

> Conversely, adding a new monitor for a message in /var/log/messages is  
> simply a matter of adding a scanf() format string to their existing list 
> of format strings - a 5-minute exercise for a junior sysadmin.

Writing a netlink interface for listening to events is not that much
harder, either....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html