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

getsockopt, of all things?

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

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...

to post comments

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.