From: Michael Tokarev <mjt@tls.msk.ru>
To: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: socket file permissions and ownership
Date: Mon, 16 May 2005 10:43:18 +0400 [thread overview]
Message-ID: <42884106.1010607@tls.msk.ru> (raw)
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
reply other threads:[~2005-05-16 6:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42884106.1010607@tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox