Please CC any reply to jmc AT xisl.com as I'm not subscribed.
I wanted to change the ownership on a unix domain socket in a program (running
as root) I was writing and I was wondering if "fchown" worked on the socket
descriptor (after I'd run "bind" of course).
It doesn't, you have to use "chown" on the path name - however "fchown"
silently does nothing, it doesn't report an error.
I don't mind it not working but I think it should report an error. This is on
2.6.3 kernel.
I tried it on HP/UX 11 and it gave EINVAL (which the HP manual page doesn't
document) and on Solaris 9 which likewise silently did nothing.
--
John Collins Xi Software Ltd http://www.xisl.com
>Please CC any reply to jmc AT xisl.com as I'm not subscribed.
>
>I wanted to change the ownership on a unix domain socket in a program (running
>as root) I was writing and I was wondering if "fchown" worked on the socket
>descriptor (after I'd run "bind" of course).
>
>It doesn't, you have to use "chown" on the path name - however "fchown"
>silently does nothing, it doesn't report an error.
I think that's normal, because chown() applies to an object in the filesystem,
while fchown() applies to the FD. (In fact, it applies to an inode.)
However, socket fd of any kind don't have an associated inode, because, well
sockets are not stored on the filesystem.
As some manpage might say, the socket thing you see in "ls -l" is just a
reference thing. When you connect to it, ls -l /proc/pidofprogram/fd/ does not
show the path, but [socket:xxxx] which shows that the filesystem object is not
used anymore.
>I don't mind it not working but I think it should report an error. This is on
>2.6.3 kernel.
What would you like it to do? EINVAL like the others or change the actual
inode's permission?
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de
On Monday 01 Nov 2004 14:20, Jan Engelhardt wrote:
> As some manpage might say, the socket thing you see in "ls -l" is just a
> reference thing. When you connect to it, ls -l /proc/pidofprogram/fd/ does
> not show the path, but [socket:xxxx] which shows that the filesystem object
> is not used anymore.
When I connect to it is the point. I want to set the permissions etc so that
only the progams that are supposed to be talking to it talk to it.
> >I don't mind it not working but I think it should report an error. This is
> > on 2.6.3 kernel.
>
> What would you like it to do? EINVAL like the others or change the actual
> inode's permission?
I don't mind. I think it's a meaninful thing to want to do, but if you can't
do it that way, fine, just let me know with some error code.
--
John Collins Xi Software Ltd http://www.xisl.com
>> As some manpage might say, the socket thing you see in "ls -l" is just a
>> reference thing. When you connect to it, ls -l /proc/pidofprogram/fd/ does
>> not show the path, but [socket:xxxx] which shows that the filesystem object
>> is not used anymore.
>
>When I connect to it is the point. I want to set the permissions etc so that
>only the progams that are supposed to be talking to it talk to it.
How about setting the permissions beforehand?
>> >I don't mind it not working but I think it should report an error. This is
>> > on 2.6.3 kernel.
>>
>> What would you like it to do? EINVAL like the others or change the actual
>> inode's permission?
>
>I don't mind. I think it's a meaninful thing to want to do, but if you can't
>do it that way, fine, just let me know with some error code.
There is no chmod op in struct proto_ops in include/linux/net.h.
Thus, all socket types should behave the same when fchmod() is used on their
FDs.
To summarize in short, you could only fchmod() a socket if you open()ed it
rather than by socket(), but otoh, open() is denied for sockets. What a
deadlock ;-)
I think it's this line in fs/open.c:
file = fget(fd);
Since you (AFAIK) can't get a "struct file" from a socketfd.
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de
On Monday 01 Nov 2004 14:49, you wrote:
> >> As some manpage might say, the socket thing you see in "ls -l" is just a
> >> reference thing. When you connect to it, ls -l /proc/pidofprogram/fd/
> >> does not show the path, but [socket:xxxx] which shows that the
> >> filesystem object is not used anymore.
> >
> >When I connect to it is the point. I want to set the permissions etc so
> > that only the progams that are supposed to be talking to it talk to it.
>
> How about setting the permissions beforehand?
We're talking about fchown not fchmod. Obviously you can set "umask" so that
the appropriate permissions are on or off.
As I've said, I don't mind the answer "no" but I think it's wrong to silently
do nothing.
What I'm trying to do is have a server process, which for various reasons has
to run as root, create a socket for clients which belong to same package and
are all set-user to "packageusername" to send requests and receive replies. I
don't want all and sundry connecting and sending lumps of data and possibly
making the server process do inappropriate things.
I don't have a problem - the server process creates the socket and then uses
"chown" on the path name before clients start to get at it. Or I can invoke
"seteuid" before creating the socket.
I just thought it would be worth drawing attention to the fact that "fchown"
silently does nothing and the whole thing is not documented anywhere (even on
OSes which give an error code). It just seemed a gap worth plugging.
--
John Collins Xi Software Ltd http://www.xisl.com
>> >When I connect to it is the point. I want to set the permissions etc so
>> > that only the progams that are supposed to be talking to it talk to it.
>>
>> How about setting the permissions beforehand?
>
>We're talking about fchown not fchmod. Obviously you can set "umask" so that
>the appropriate permissions are on or off.
Whoops. Well, you said "permissions" in the topmost quoted thing.
Anyway, you could use ACLs to restrict connecting to a PF_UNIX
socket on a per user/group basis.
>I just thought it would be worth drawing attention to the fact that "fchown"
>silently does nothing and the whole thing is not documented anywhere (even on
>OSes which give an error code). It just seemed a gap worth plugging.
Now the message is clear. Glibc info pages maintained by
[email protected] (IIRC), man pages now maintained by (sorry forgot
the addr, but take a look on LKML archive for this day).
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de
Jan Engelhardt wrote:
>How about setting the permissions beforehand?
This makes you susceptible to TOCTTOU (race condition) attacks in some
cases. Often, the only way to change ownership or permissions of a file
you want to operate on securely is to use fchown()/fchmod() etc.
It came as a surprise to me that open() + fchown()/fchmod() does not
work in some cases that chown()/chmod() do. I wonder whether this has
any effect on applications. Could this result in security holes in
applications that are unaware of this property?