![]() | |||||||||||||
Messages in this thread |
Unlike some other *nix flavours, linux honors normal AF_LOCAL socket file permissions and ownership -- eg, you can't connect to a socket if file permissions indicate you can't read/write the file. But at the same time, linux ignores *changes* in said permissions/ownership. The code: int sock; struct sockaddr_un sun; sock = socket(PF_LOCAL, SOCK_STREAM, 0); unlink(sun.sun_path); bind(sock, (struct sockaddr *)&sun, sizeof(sun)); fchmod(sock, 0660); fchown(sock, 10, 20); -- in this fragment (initialisation omitted for brevity), fchown() and fchmod() calls succeed but does exactly nothing, ie, no permission and ownership change occurs. "Plain" chmod()/chown() (when referring to the file by name, not by filedescriptor) works. I was thinking about actually using the linux feature (linux checking socket permissions), but it isn't quite possible to do in a safe way. That is, I want to be able to create a socket with given permissions and ownership from within a root-owned process in a directory not writable by the owner of the socket to be created. I can work around fchmod() by altering umask() prior to bind() call. But for owner... Possible scenarios: fchown(sock, s_owner, s_group) -- gets ignored by linux seteuid(s_owner) before bind() -- s_owner does not have permissions to create file(s) in the given directory chown(sun.sun_path, s_owner, s_group) -- unsafe from security point of view, if parent directory isn't owned by root. I know no other way to set ownership. And all the above 3 does not work. So the obvious question: what should linux do, stop honoring socket permissions and continue ignoring fch*() calls, or continue using permissions AND implement fch*() calls? Current situation is.. wrong. IMHO. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-05-16 08:46 [from the cache] ©2003-2008 | |||||||||||||