Hi Al, I'd like to suggest a possible new flag for unlinkat(2): AT_DEFER_UNLINK. It would be useful for the following scenario: Process A, running as root, binds a (non-abstract) Unix socket.It then forks and execs process B, which runs as nobody, which inherits the socket and listens in the socket. When B ends using the socket, it closes it, but it can't unlink it, as the file is owned by root.
Process A can't unlink(2) the file right after creation, because the file name is used by clients that want to connect to the server, and of course, the filename is the interface.
An option would be to chown(2) the file, but that may not be desirable.Another option is finding a way to communicate back with A to ask for the removal of the socket; that would be insane to implement, compared to other options.
My proposal is to tell the kernel that I want the file to be removed when the last fd to it has been closed.
It could be done in an unlink(2) call, or with a flag to bind (the current API doesn't have flags, which is why I thought of unlinkat(2)).
I know this is basically mirroring the behavior of abstract sockets with file-backed unix sockets. And maybe your answer is to use abstract sockets. I'm trying to convince my client that abstract sockets are the way to go. But I was still wondering, while I try to convince him, if this would be an interesting feature for the kernel anyway.
Another option would be to give SO_REUSEADDR a meaning with Unix sockets, so that leaving socket files in the filesystem wouldn't be a real issue.
I'm not sure if there's a situation where due to having network namespace isolation but shared mount points, file-backed sockets would be the only solution. I'm still trying to investigate the full context of my client to make sure file-backed unix sockets are really necessary.
Cheers, Alex -- Alejandro Colomar <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
