1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
[[!tag open_issue_glibc]]
# IRC, unknown channel, unknown date
<pinotree> Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2722
<pinotree> 2722: Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2724
<pinotree> \o/
<youpi> \o/
<pinotree> the patch is even short, after all: http://paste.debian.net/54795/
--- a/sysdeps/mach/hurd/sendmsg.c
+++ b/sysdeps/mach/hurd/sendmsg.c
@@ -18,6 +18,7 @@
#include <errno.h>
#include <string.h>
+#include <unistd.h>
#include <sys/socket.h>
#include <sys/un.h>
@@ -45,6 +46,7 @@
mach_msg_type_number_t amount;
int dealloc = 0;
int i;
+ struct sockaddr_storage sa;
/* Find the total number of bytes to be written. */
len = 0;
@@ -122,6 +124,34 @@
err = EIEIO;
}
+ memset (&sa, 0, sizeof (struct sockaddr_storage));
+ if (addr)
+ {
+ memcpy (&sa, addr, addr_len);
+ }
+ else
+ {
+ getsockname (fd, (struct sockaddr *) &sa, &addr_len);
+ }
+ addr = (struct sockaddr_un *) &sa;
+ if (message && (addr->sun_family == AF_LOCAL))
+ {
+ struct cmsghdr *cm;
+ struct msghdr *m = (struct msghdr *) message;
+ for (cm = CMSG_FIRSTHDR (m); cm; cm = CMSG_NXTHDR (m, cm))
+ {
+ if (cm->cmsg_level == SOL_SOCKET && cm->cmsg_type == SCM_CREDS)
+ {
+ struct cmsgcred *cred = (struct cmsgcred *) CMSG_DATA (cm);
+ cred->cmcred_pid = __getpid ();
+ cred->cmcred_uid = __getuid ();
+ cred->cmcred_euid = __geteuid ();
+ cred->cmcred_gid = __getgid ();
+ cred->cmcred_ngroups = getgroups (sizeof (cred->cmcred_groups) / sizeof (gid_t), cred->cmcred_groups);
+ }
+ }
+ }
+
err = HURD_DPORT_USE (fd,
({
if (err)
<youpi> what checks that the pid is correct?
<youpi> and uid, etc.
<pinotree> hm?
<youpi> credential is not only about one claiming to the other his uid & such
<youpi> it's about the kernel or whatever authority tell to an end the identity of the other end
<pinotree> yep
<pinotree> but given that the data is then send to pflocal, this code is the last part that runs on the application side
<youpi> pflocal could as well just request the info from proc
<youpi> it will have to anyway, to check that it's true
<pinotree> hm
<pinotree> yeah, though about that, chose this approach as "quicker" (of course not definitive)
<youpi> well at least it shows we're able to transmit something :)
<pinotree> well it just manipulates the data which gets send nicely already ;)
<youpi> but really, it's most probably up to pflocal to check authentication from proc and give it to the other end
<youpi> the application sender part would be just the RPC authentication calls
<youpi> Mmm, just realizing: so receiver part already exists actually, right?
<youpi> (since it's just about letting the application reading from the message structure)
<pinotree> yep
<youpi> ok, good :)
## IRC, freenode, #hurd, 2011-08-11
< pinotree> (but that patch is lame)
## IRC, freenode, #hurd, 2013-05-09
<gnu_srs> youpi: Since you are online tonight, which authentication
callbacks to be used for SCM_CREDS calls.
<gnu_srs> I have working code and need to add this to make things
complete. The auth server, lib* or where?
<youpi> I don't understand the question
<gnu_srs> authentication callbacks like for SCM_RIGHTS, see
<gnu_srs>
http://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html
<youpi> I still don't understand: what are you trying to do actually?
<gnu_srs> solving the SCM_CREDS propbems with e.g. dbus.
<youpi> so what is the relation with pinotree's patch on the page above?
<youpi> (I have no idea of the current status of all that)
<gnu_srs> his patch was not merged, right? have to shut down, sorry, bbl,
gn8
<pinotree> that patch was not merged since it is not in the correct place
<youpi> as I said, I have no idea about the status
<pinotree> youpi: basically, it boils down to knowing, when executing the
code implementing an rpc, who requested that rpc (pid, uid, gid)
<youpi> i.e. getting information about the reply port for instance?
<youpi> well that might be somehow faked
<youpi> (by perhaps giving another task's port as reply port)
<pinotree> for example (which would be the code path for SCM_CREDS), when
you call call the socket sendmsg(), pflocal would know who did that rpc
and fill the auxilliary data)
<pinotree> s,)$,,
<pinotree> youpi: yes, i know about this faking issue, iirc also antrik
mentioned quite some time ago
<youpi> ok
<pinotree> that's one of the (imho) two issues of this
<pinotree> my hurd-foo is not enough to know whether there are solutions to
the problem above
### IRC, freenode, #hurd, 2013-05-14
<gnu_srs> Hi, regarding SCM_CREDS, I have some working code in
sendmsg.c. Now I need to make a callback to authenticate the pid, uid,
etc
<gnu_srs> Where to hook call that into pflocal?
<gnu_srs> the auth server?
<gnu_srs> maybe _io_restrict_auth is the correct call to use (same as for
SCM_RIGHTS)?
### IRC, freenode, #hurd, 2013-05-17
<gnu_srs> I'm working on the scm credentials right now to enable (via dbus)
more X window managers to work properly.
<gnu_srs> seems to be rather tricky:-(
<pochu> gnu_srs: I guess you also need SCM_CREDS, right?
<gnu_srs> hi pochu, that's what I'm working on, extending your SCM_RIGHTS
work to SCM_CREDS
<pinotree> that's what i did as proof, years ago?
<gnu_srs> it would be good to know which server calls to make, I'll be back
with proposals of functions to use.
<pinotree> there was a talk, years ago when i started with this, and few
days ago too
<pinotree> every methods has its own drawbacks, and basically so far it
seems that in every method the sender identity can be faked somehow
<gnu_srs> pinotree: Yes of course your patch was perfect, but it seemed
like people wanted a server acknowledgement too.
<pinotree> no, my patch was not perfect at all
<pinotree> if it was, it would have been cleaned up and sent few years ago
already
---
See also [[dbus]], [[service_solahart_jakarta_selatan__082122541663/pflocal_socket_credentials_for_local_sockets]] and
[[service_solahart_jakarta_selatan__082122541663/pflocal_reauth]].
|
