linux-kernel - Re: [RFC] 0/11 fanotify: fscking all notifiction and file access system (intended for antivirus scanning and file indexers)

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: <20081002214846.60560cae@lxorguk.ukuu.org.uk>
Date:	Thu, 2 Oct 2008 21:48:46 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Eric Paris <eparis@...hat.com>
Cc:	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	arjan@...radead.org, bunk@...nel.org, tytso@....edu,
	tvrtko.ursulin@...hos.com, david@...g.hm, hch@...radead.org,
	andi@...stfloor.org, viro@...IV.linux.org.uk, peterz@...radead.org,
	Jonathan.Press@...com, riel@...hat.com, greg@...ah.com
Subject: Re: [RFC] 0/11 fanotify: fscking all notifiction and file access
 system (intended for antivirus scanning and file indexers)

> struct fan_sockaddr {
> 	int version;
> 	unsigned int mask;
> 	pid_t pid;
> 	pid_t tgid;
> 	int f_flags;
> }
> 
> so this will be a binary interface for metadata.  Sending the metadata
> about the open fd up the sockaddrs is very slick, but not easily
> extended that I can see.  Guess we need to get the metadata right the
> first time.

Usual way socket stuff covers for that is to stick

	unsigned int __unused[8];

or similar on the end...

> PF_FAN system.  This new fd from connect can then take commands using
> either sendmsg() or setsockopt() or really anything since it doesn't
> have a 'real file' on the backend.

That is the normal socket approach. Eg in traditional BSD interfaces for
IP routing you created an AF_INET socket and frobbed with it.

> So the alternative would be that I could make ALL listener->kernel
> communication go over the fd that came from connect().  Setting a

Probably a lot saner

> includes types and lens.  Is is it bad to have a fd whose only
> implemented function is setsockopt?

Not really. Lots of socket types have operations that are essentially

	fd = socket(...)
	ioctl(fd, ....);
	close(fd);

or similar. Traditionally ioctl is used for system changing stuff but
that is just tradition.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/