Hi all,
while trying gamin (a file alteration monitor, like fam), I found that it
refuses to work because it detects that the local sockets it creates
have "too much permissions" (that is, 777).
As I see in our code, local sockets are always created with this
mode, regardless of the user's umask. Is this correct? And if so,
why?
FreeBSD, BSD and Linux respect the umask. If our behavior is
not correct, what about the following patch?
Index: uipc_usrreq.c
RCS file: /,v
retrieving revision 1.83
diff -u -r1.83 uipc_usrreq.c
uipc_usrreq.c 16 Jun 2005 14:36:42 -0000 1.83
uipc_usrreq.c 21 Aug 2005 21:16:11 -0000
@@ -638,7 +638,7 @@
}
VATTR_NULL(&vattr);
vattr.va_type = VSCK;
- vattr.va_mode = ACCESSPERMS;
+ vattr.va_mode = ACCESSPERMS & ~(p->p_cwdi->cwdi_cmask);
VP_LEASE(nd.ni_dvp, p, p->p_ucred, LEASE_WRITE);
error = VP_CREATE(nd.ni_dvp, &nd.ni_vp, &nd.ni_cnd, &vattr);
vn_finished_write(mp, 0);
Thanks,

jmmv84 (AT) gmail (DOT) com ("Julio M. Merino Vidal") writes:

>while trying gamin (a file alteration monitor, like fam), I found that it
>refuses to work because it detects that the local sockets it creates
>have "too much permissions" (that is, 777).

Many UNIX variants ignore the mode bits for local sockets. This is
probably just 'traditional' but also makes local sockets more similar
to network sockets.

>FreeBSD, BSD and Linux respect the umask. If our behavior is
>not correct, what about the following patch?

behaviour is at least not consistent as connect() seems to honor
the mode bits when you change them with chmod.

Does fchmod() work?

8/22/05, Thor Lancelot Simon <tls (AT) rek (DOT) tjls.comwrote:
Sun, Aug 21, 2005 at 11:25:56PM +0200, Julio M. Merino Vidal wrote:
Hi all,

while trying gamin (a file alteration monitor, like fam), I found that it
refuses to work because it detects that the local sockets it creates
have "too much permissions" (that is, 777).

As I see in our code, local sockets are always created with this
mode, regardless of the user's umask. Is this correct? And if so,
why?

Because that's how BSD Unix always did it.

The portable solution for restricting access to a Unix domain socket is
to put it in a directory with appropriate permissions.

Aha; thanks for the explanation.

In fact, gamin is doing so. It creates a directory with 700 permissions
and then creates the socket inside it. I don't know wtf does it barf
later on when it sees that the socket has 777 permissions, given that
it has done things right.

However, there
is code floating around out there that expects sockets to be created
with appropriate modes (respecting the umask) and I see no harm at all
in causing our implementation to work that way. I suggest that you do
so.

Yeah, sounds reasonable. But IMH, we should explain somewhere
(bind(2) ?) that this is not how things should be done (I'll do this change
too if I commit the "fix").

8/22/05, Michael van Elst <mlelstv (AT) serpens (DOT) dewrote:
jmmv84 (AT) gmail (DOT) com ("Julio M. Merino Vidal") writes:

>while trying gamin (a file alteration monitor, like fam), I found that it
>refuses to work because it detects that the local sockets it creates
>have "too much permissions" (that is, 777).

Many UNIX variants ignore the mode bits for local sockets. This is
probably just 'traditional' but also makes local sockets more similar
to network sockets.

>FreeBSD, BSD and Linux respect the umask. If our behavior is
>not correct, what about the following patch?

behaviour is at least not consistent as connect() seems to honor
the mode bits when you change them with chmod.

Does fchmod() work?

No, it doesn't. It returns EINVAL.

I also checked what Linux does and, while it returns success, it does
not change the permissions.

chmod works correctly, though.

What should we do then? Make fchmod(2) work with sockets too?

Thanks.

Sun, 21 Aug 2005 22:29:22 +0000 (UTC)
mlelstv (AT) serpens (DOT) de (Michael van Elst) wrote:

behaviour is at least not consistent as connect() seems to honor
the mode bits when you change them with chmod.

Does fchmod() work?

Yes I use fchmod(2) in most of my code which creates AF_LCAL sockets
and it works fine on BSDs and Linux It is not atomic with socket
creation of course, but considering that it can be done before using
listen(2) for SCK_STREAM it still seems reasonable

Sun, 21 Aug 2005 22:29:22 +0000 (UTC)
mlelstv (AT) serpens (DOT) de (Michael van Elst) wrote:
Does fchmod() work?
err sorry, I meant chmod(2)
Matt