*getsockopt*, of all things? [LWN.net]

getsockopt, of all things?

Posted Jul 2, 2009 16:22 UTC (Thu) by RobSeace (subscriber, #4435)
In reply to: *getsockopt*, of all things? by quotemstr
Parent article: The fanotify API

Yeah, I don't understand why even normal I/O wouldn't be sufficient, without even needing control messages... But, even control messages sound better than using a socket option for something like this...

How exactly are apps to be notified that a new event is ready to be retrieved? Will they select()/poll() as readable still, even though you don't actually read from them to get the event data?

to post comments

getsockopt, of all things?

Posted Jul 2, 2009 16:39 UTC (Thu) by quotemstr (subscriber, #45331) [Link] (4 responses)

Normal IO isn't sufficient because we need to send a file descriptor over the socket. I think the original author decided to go with a new socket family because there's no way to send a file descriptor over an AF_NETLINK socket.

Speaking of which, AF_NETLINK seems to be exactly what's needed here, just extended to support sending file descriptors over ancillary messages.

Of course, the other option is to just create a device node and use ioctl. That's frowned upon, but what harm does it really do? Plus, using a device node allows you to restrict access to the device using all the usual UNIX-permission-and-POSIX-ACL goodness available anywhere else.

getsockopt, of all things?

Posted Jul 2, 2009 18:01 UTC (Thu) by RobSeace (subscriber, #4435) [Link] (3 responses)

Oh yeah, I kind of missed the whole FD passing part of the API... (Is that really necessary, instead of, say, giving the filename and letting the app do its own open, or whatever it wants to do to the file?)

But, yeah, I think your netlink + control message idea sounds a lot better than this method, anyway... I still don't get how the app will be notified when it's supposed to do the getsockopt(), unless select()/poll() gets kluged up to falsely indicate readability (when you can't really read from it) when one of these events are ready to be retrieved...

getsockopt, of all things?

Posted Jul 2, 2009 18:05 UTC (Thu) by quotemstr (subscriber, #45331) [Link] (1 responses)

giving the filename and letting the app do its own open

Racetastic, yes?

select()/poll() gets kluged up to falsely indicate readability

Well, to be fair, select even on ordinary objects doesn't indicate readability. It's more like "it might have been readable sometime in the recent past, if you're lucky". That's why you always call select() on non-blocking sockets, and why you always prepare to get EAGAIN even after select() reports a file descriptor to be readable.

getsockopt, of all things?

Posted Jul 2, 2009 18:41 UTC (Thu) by RobSeace (subscriber, #4435) [Link]

Yeah, but this sounds even worse than that, since it was never truly readable at all, but merely has a sockopt ready to be gotten... *shrug* It just sounds like an ugly kluge to me...

How about just treating the socket as if it were a listening socket, and use accept() to return the FD (and fill the other related necessary info into the returned client sockaddr)? Then, readability on the listener fits the already established model for normal listening sockets, to indicate a new connection to accept, and no need for any klugey FD passing behavior... Of course, returning a non-socket FD from accept() is probably just as ugly a kluge, I suppose... *shrug*

getsockopt, of all things?

Posted Jul 10, 2009 23:28 UTC (Fri) by efexis (guest, #26355) [Link]

"(Is that really necessary, instead of, say, giving the filename and letting the app do its own open, or whatever it wants to do to the file?)"

That would require the scanner (or whatever) to be running with permission to open any file on the file system... you might not want that. Much more secure to pass it a read-only already-open filehandle, and allow it to run as an unprivileged user.