summaryrefslogtreecommitdiff
path: root/open_issues/dbus.mdwn
blob: b3bebf48eb733f679a034f3bd208acb6a3bed0ca (plain)
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
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 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_hurd]]

The dbus problems are due to missing scm credentials [[sendmsg_scm_creds]] and socket credentials
[[pflocal_socket_credentials_for_local_sockets]]. There was also a problem with short timeout in 
[[select]], but that has been solved in Debian by setting a minimum timeout of 1ms.

[[!toc]]


# IRC, freenode, #hurd, 2011-11-26

    <antrik> BTW, how much effort is necessary to fix dbus?
    <pinotree> basically, have pflocal know who's the sender
      (pid/uid/gid/groups) in the socket send op


# IRC, freenode, #hurd, 2011-12-16

    <braunr> pinotree: what's the problem with dbus ?
    <pinotree> braunr: select() returning 0 changed fd's with very short (eg <
      1ms) timeouts when there are actually events;

[[select]].

    <pinotree> and missing socket credentials

[[sendmsg_scm_creds]].

    <braunr> oh
    <braunr> which socket creds interface ?
    <pinotree> bsd, i.e. with SCM_CREDENTIALS payload for cmsg on
      {recv,send}msg()
    <braunr> ok
    <braunr> SCM_RIGHTS too ?
    <braunr> the select issue seems weird though
    <pinotree> hm no, that's for passing fd's to other processes
    <braunr> is it specific to pflocal or does dbus use pfinet too ?
    <pinotree> iirc on very short timeouts the application has no time waiting
      for the reply of servers
    <braunr> i see
    <pinotree> braunr: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79358
    <braunr> thanks
    <pinotree> (the interesting messages are from #53 and on)
    <braunr> 2000 eh ... :)
    <braunr> hm i agree with neal, i don't understand why the timeout is given
      to the kernel as part of the mach_msg call


# IRC, freenode, #hurd, 2011-12-20

    <braunr> hm, i don't see any occurrence of SCM_CREDENTIALS in dbus
    <braunr> only SCM_RIGHTS
    <pinotree> braunr: yes, that one
    <braunr> oh
    <braunr> i thought you said the opposite last time
    <pinotree> dbus/dbus-sysdeps-unix.c, write_credentials_byte and
      _dbus_read_credentials_socket (with #define HAVE_CMSGCRED)
    <braunr> hm
    <braunr> which version ?
    <braunr> i don't see anything in 1.4.16
    <pinotree> 1.4.16
    <braunr> grmbl
    <braunr> ah, i see
    <braunr> SCM_CREDS
    <pinotree> if you want, i have a simplier .c source with it
    <braunr> no i'm just gathering info
    <pinotree> ok
    <braunr> what's the deal with SCM_CREDS and SCM_CREDENTIALS ?
    <braunr> bsd vs sysv ?
    <braunr> oh, http://lists.debian.org/debian-hurd/2002/03/msg00135.html
    <braunr> so we actually do want both SCM_CREDS and SCM_RIGHTS for debus
    <braunr> dbus
    <pinotree> SCM_RIGHTS is a different matter, it is for passing fd's
    <braunr> yes
    <braunr> but it's used by dbus
    <braunr> so if we can get it, it should help too
    <pinotree> there's a preliminary patch for it done by emilio time ago, and
      iirc it's applied to debian's glibc
    <braunr> ah, he changed the libc
    <braunr> right, that's the only sane way
    <pinotree> iirc roland didn't like one or more parts of it (but i could be
      wrong)
    <braunr> ok


# IRC, freenode, #hurd, 2013-07-17

    <teythoon> btw pinotree, what happened to your efforts to make dbus work?
    <pinotree> not much, my initial patch was just a crude hack, a better
      solution requires more thinkering and work 
    <teythoon> yes, ive seen that
    <teythoon> but that was only a tiny patch against the libc, surely there
      must be more to that?
    <pinotree> not really
    <teythoon> and the proper fix is to patch pflocal to query the auth server
      and add the credentials?
    <pinotree> possibly
    <teythoon> that doesn't sound to bad, did you give it a try?
    <pinotree> not really, got caught in other stuff


# IRC, freenode, #hurd, 2013-09-02

    <gnu_srs1> something is wrong with libc0.3 since the switch to 2.17. dbus
      does not run any longer when rebuilt
    <gnu_srs1> the latest build of dbus was with 2.13: libc0.3-dev: already
      installed (2.13-38)
    <pinotree> debug it
    <gnu_srs1> Yes, I will. Maybe somebody could rebuild it and verify my
      findings?
    <pinotree> gnu_srs1: your finding is "doesn't work", which is generic and
      does not help without investigation
    <gnu_srs1> just rebuild it and: e.g. ./build-debug/bus/dbus-daemon --system
      (--nofork)
    <pinotree> gnu_srs1: please, debug it
    <gnu_srs1> I have partially already. But maybe the problems only shows on
      my box. I'll rebuild on another box before continuing debugging.
    <pinotree> gnu_srs1: are you, by chance, running a libc or something else
      with your scm_creds work?
    <gnu_srs1> I did, but I've backed to 2.17-92 right now.
    <gnu_srs1> sane problem with dbus on another box, something's fishy:-(
    <gnu_srs1> braunr: any good way to find out if the dbus problems are with
      libpthread? Setting a breakpoint with libc0.3-dbg installed.
    <braunr> gnu_srs1: i don't know

See [[glibc]], *Missing interfaces, amongst many more*, *`SOCK_CLOEXEC`*.


# IRC, freenode, #hurd, 2013-09-04

    <gnu_srs> Hi, looks like dbus requires abstract socket namespace: #undef
      HAVE_ABSTRACT_SOCKETS What's missing?
    <pinotree> uh?
    <pinotree> abstract unix sockets are a Linux feature, and surely it is not
      mandatory for dbus
    <gnu_srs> Looks like dbus exits if they are not supported:
    <gnu_srs>  dbus_set_error (error, DBUS_ERROR_NOT_SUPPORTED,  "Operating
      system does not support abstract socket namespace\n");        _dbus_close
      (listen_fd, NULL);  1061       return -1;
    <pinotree> that is enclosed in a if (abstract)
    <pinotree> and that parameter is set to true in other places (eg
      dbus/dbus-server-unix.c) only when HAVE_ABSTRACT_SOCKETS is defined
    <pinotree> so no, abstract sockets are not mandatory
    <gnu_srs> Well this code is executed e.g. when running emacs remotely in
      X. Have to dig deeper then to see why.
    <pinotree> maybe it could have to do the fact that your dbus server is
      running in linux and runs by default using such sockets type
    <pinotree> but yes, you need to dig better
    <gnu_srs> pinotree: You are right. when running natively the problem is:
    <pinotree> *drums*
    <gnu_srs> Manually: Process /usr/lib/at-spi2-core/at-spi-bus-launcher
      exited with status 1
    <pinotree> eh?
    <gnu_srs> Error retrieving accessibility bus address:
      org.freedesktop.DBus.Error.Spawn.ChildExited: ^
    <pinotree> most probably that service does not start due to the lack of
      socket credentials which affects dbus
    <pinotree> uninstall or disable those additional services, they are not
      your problem
    <gnu_srs> credentials is enabled. which services to remove?
    <pinotree> dunno


# IRC, freenode, #hurd, 2013-09-11

    <gnu_srs> Hi, looks like frebsd had (2008) the same problem as hurd when
      sending credentials over PF_INET: 
    <gnu_srs>
      http://lists.freebsd.org/pipermail/freebsd-hackers/2008-May/024577.html
    <gnu_srs> Since the dbus code is about the same now (2013), maybe they
      added support?
    <gnu_srs> The next message in the thread confirms that the dbus code is
      invalid, does anybody have pointers?
    <pinotree> from what i've seen so far, socket credentials are done only for
      local sockets (ie PF_UNIX)
    <pinotree> i don't see how things like uid/gid/pid of the socket endpoint
      can have anything to do with AF_INET
    <pinotree> and socket credentials in dbus are used only in the [local]
      socket transport, so there's no issue


# IRC, freenode, #hurd, 2013-09-12

    <gnu_srs> pinotree: Yes, there is an issue with dbus and AF_INET, see
      test/corrupt.c: tests /corrupt/tcp and /corrupt/byte-order/tcp:-/
    <pinotree> gnu_srs: what's wrong with those? they are just testing the
      connection over a tcp socket
    <pinotree> as said above, socket credentials shouldn't be used in such
      cases
    <gnu_srs> They are, see also test/relay.c: /relay and /limit tests:-(
    <pinotree> how are they?
    <pinotree> please be more specifc...
    <gnu_srs> Just run the tests yourself with DBUS_VERBOSE=1
    <pinotree> you are claiming there is a problem, so please specify what is
      the actual issue
    <gnu_srs>  DBUS_VERBOSE=1 build-debug/test/test-relay 
    <pinotree> you are claiming there is a problem, so please specify what is
      the actual issue
    <gnu_srs> same with test-corrupt
    <gnu_srs> look at the verbose output:  Failed to write credentials: Failed
      to write credentials byte: Invalid argument
    <gnu_srs> coming from pfinet since PF_INET is used.
    <pinotree> check what it does on linux then
    <pinotree> put an abort() at the start of the read/write socket credential
      functions in dbus-sysdeps-unix.c and see whether it is triggered also on
      linux
    <gnu_srs> SO_PEERCRED is used for linux and LOCAL_CREDS is used for
      kfreebsd, so we are on our own here:-/
    <pinotree> and linux' SO_PEERCRED works also on AF_INET sockets? i'd doubt
      it
    <gnu_srs>
      http://stackoverflow.com/questions/10037086/so-peercred-vs-scm-credentials-why-there-are-both-of-them
    <pinotree> yes, i know the difference, but please read what i asked again
    <gnu_srs> I'll check to be sure...
    <braunr> gnu_srs: user credentials are not supposed to be passed through an
      AF_INET socket
    <braunr> how hard is that to understand ?
    <gnu_srs> OK, linux use send since CMSGCREDS is not defined to write
      credentials. Working on how they are received.
    <gnu_srs> braunr: I do understand, but the dbus code tries to do that for
      Hurd:-(
    <pinotree> then it should do that on linux too
    <pinotree> (since the local socket credentials code is isolated in own
      functions, and they are called only for the unix transport)
    <gnu_srs> Happiness:-D, almost all dbus tests pass!
    <gnu_srs> 17(17) dbus tests pass:)
    <braunr> gnu_srs: hopefully your patch does things right
    <gnu_srs> which patch
    <braunr> adding credentials through unix socket
    <braunr> isn't that what you're doing ?
    <gnu_srs> the mail to MLs is from the stock installed packages.
    <braunr> ?
    <gnu_srs> the test reports are with the SCM_CREDS patches, but I stumbled
      on the SCM_RIGHTS issues reported to MLs
    <gnu_srs> no patches applied, just test the attached file yourself.
    <braunr> so what's your work about ?
    <gnu_srs> I'm working on SCM_CREDS, yes, and created patches for dbus,
      glib2.0 and libc.
    <gnu_srs> the mail was about some bug in the call to io_restrict_auth in
      sendmsg.c: without any of my patches applied (another image) 
    <teythoon> gnu_srs: you have to give us more context, how are we supposed
      to know how to find this sendmsg.c file?
    <pinotree> (it's in glibc, but otherwise the remark is valid)
    <pinotree> s/otherwise/anyway/


# Emails

# IRC, freenode, #hurd, 2013-10-16

    <braunr> gnu_srs: how could you fail to understand credentials need to be
      checked ?
    <gnu_srs> braunr: If data is sent via sendmsg, no problem, right?
    <braunr> gnu_srs: that's irrelevant
    <gnu_srs> It's just to move the check to the receive side.
    <braunr> and that is the whole problem
    <braunr> it's not "just" doing it
    <braunr> first, do you know what the receive side is ?
    <braunr> do you know what it can be ?
    <braunr> do you know where the corresponding source code is to be found ?
    <gnu_srs> please, describe a scenario where receiving faulty ancillary data
      could be a problem instead
    <braunr> dbus
    <braunr> a user starting privileged stuff although he's not part of a
      privileged group of users for example
    <braunr> gnome, kde and others use dbus to pass user ids around
    <braunr> if you can't rely on these ids being correct, you can compromise
      the whole system
    <braunr> because dbus runs as root and can give root privileges
    <braunr> or maybe not root, i don't remember but a system user probably
    <pinotree> "messagebus"
    <gnu_srs> k!
    <braunr> see http://www.gnu.org/software/hurd/open_issues/dbus.html
    <braunr> IRC, freenode, #hurd, 2013-07-17
    <braunr> <teythoon> and the proper fix is to patch pflocal to query the
      auth server and add the credentials?
    <braunr> <pinotree> possibly
    <braunr> <teythoon> that doesn't sound to bad, did you give it a try?


# IRC, freenode, #hurd, 2013-10-22

    <gnu_srs> I think I have a solution on the receive side for SCM_CREDS :)

    <gnu_srs> A question related to SCM_CREDS: dbus use a zero data byte to get
      credentials sent.
    <gnu_srs> however, kfreebsd does not care which data (and credentials) is
      sent, they report the credentials anyway
    <gnu_srs> should the hurd implementation do the same as kfreebsd?
    <youpi> gnu_srs: I'm not sure to understand: what happens on linux then?
    <youpi> does it see zero data byte as being bogus, and refuse to send the
      creds?
    <gnu_srs> linux is also transparent, it sends the credentials independent
      of the data (but data has to be non-null)
    <youpi> ok
    <youpi> anyway, what the sending application writes does not matter indeed
    <youpi> so we can just ignore that
    <youpi> and have creds sent anyway
    <braunr> i think the interface normally requires at least a byte of data
      for ancilliary data
    <youpi> possibly, yes
    <braunr>        To pass file descriptors or credentials over a SOCK_STREAM,
      you need to  send  or
    <braunr>        receive  at  least  one  byte  of  non-ancillary  data  in
      the same sendmsg(2) or
    <braunr>        recvmsg(2) call.
    <braunr> but that may simply be linux specific
    <braunr> gnu_srs: how do you plan on implementing right checking ?
    <gnu_srs> Yes, data has to be sent, at least one byte, I was asking about
      e.g. sending an integer 
    <braunr> just send a zero
    <braunr> well
    <braunr> dbus already does that
    <braunr> just don't change anything
    <braunr> let applications pass the data they want
    <braunr> the socket interface already deals with port rights correctly
    <braunr> what you need to do is make sure the rights received match the
      credentials
    <gnu_srs> The question is to special case on a zero byte, and forbid
      anything else, or allow any data.
    <braunr> why would you forbid 
    <braunr> ?
    <gnu_srs> linux and kfreebsd does not special case on a received zero byte
    <braunr> same question, why would you want to do that ?
    <gnu_srs> linux sends credentials data even if no SCM_CREDENTIALS structure
      is created, kfreebsd don't
    <braunr> i doubt that
    <gnu_srs> To be specific:msgh.msg_control = NULL; msgh.msg_controllen = 0;
    <braunr> bbl
    <gnu_srs> see the test code:
      http://lists.debian.org/debian-hurd/2013/08/msg00091.html
    <braunr> back
    <braunr> why would the hurd include groups when sending a zero byte, but
      only uid when not ?
    <gnu_srs> ?
    <braunr> 1) Sent credentials are correct:
    <braunr> no flags: Hurd: OK, only sent ids
    <braunr> -z Hurd: OK, sent IDs + groups
    <braunr> and how can it send more than one uid and gid ?
    <braunr> "sent credentials are not honoured, received ones are created"
    <gnu_srs> Sorry, the implementation is changed by now. And I don't special
      case on a zero byte.
    <braunr> what does this mean ?
    <braunr> then why give me that link ?
    <gnu_srs> The code still applies for Linux and kFreeBSD. 
    <gnu_srs> It means that whatever you send, the kernel emits does not read
      that data: see
    <gnu_srs> socket.h: before  struct cmsgcred: the sender's structure is
      ignored ...
    <braunr> do you mean receiving on a socket can succeed with gaining
      credentials, although the sender sent wrong ones ?
    <gnu_srs> Looks like it. I don't have a kfreebsd image available right now.
    <gnu_srs> linux returns EPERM
    <braunr> anyway
    <braunr> how do you plan to implement credential checking ?
    <gnu_srs> I'll mail patches RSN


# IRC, freenode, #hurd, 2013-11-03

    <gnu_srs> Finally, SCM_CREDS (IDs) works:) I was on the right track all the
      time, it was just a small misunderstanding.
    <gnu_srs> remains to solve the PID check
    <youpi> gnu_srs: it should be a matter of adding
      proc_user/server_authenticate
    <gnu_srs> there are no proc_user/server_authenticate RPCs?
    <gnu_srs> do you mean adding them to process.defs (and implement them)?
    <youpi> gnu_srs: I mean that, yes


# IRC, freenode, #hurd, 2013-11-13

    <gnu_srs> BTW: I have to modify the SCM_RIGHTS patch to work together with
      SCM_CREDS, OK?
    <youpi> probably
    <youpi> depends on what you change of course


# IRC, freenode, #hurd, 2013-11-15

    <gnu_srs> Hi, any ideas where this originates, gdb? warning: Error setting
      exception port for process 9070: (ipc/send) invalid destination port
    <braunr> gnu_srs: what's process 9070 ?
    <gnu_srs> braunr: It's a test program for sending credentials over a
      socket. Have to create a reproducible case, it's intermittent.
    <gnu_srs> The error happens when running through gdb and the sending
      program is chrooted:
    <gnu_srs> -rwsr-sr-x 1 root root 21156 Nov 15 15:12
      scm_rights+creds_send.chroot


## IRC, freenode, #hurd, 2013-11-16

    <gnu_srs> Hi, I have a problem debugging a suid program, see
      http://paste.debian.net/66171/
    <gnu_srs> I think this reveals a gnumach/hurd bug, it makes things behave
      strangely for other programs.
    <gnu_srs> How to get further on with this?
    <gnu_srs> Or can't I debug a suid program as non-root?
    <pochu> gnu_srs: if gdb doesn't work for setuid programs on hurd, I suppose
      you could chmod -s the binary you're trying to debug, login as root and
      run it under gdb
    <gnu_srs> pochu: When logged in as root the program works, independent of
      the s flag setting.
    <pochu> right, probably the setuid has no effect in that case because your
      effective uid is already fine
    <pochu> so you don't hit the gdb bug in that case
    <pochu> (just guessing)
    <gnu_srs> It doesn't work in Linux either, so it might be futile.
    <gnu_srs> trying
    <pochu> hmm that may be the expected behaviour. after all, gdb needs to be
      priviledged to debug priviledged processes
    <gnu_srs> Problem is that it was just the suid properties I wanted to
      test:(
    <braunr> gnu_srs: imagine if you could just alter the code or data of any
      suid program just because you're debugging it


## IRC, freenode, #hurd, 2013-11-18

    <gnu_srs> Hi, is the code path different for a suid program compared to run
      as root?
    <gnu_srs> Combined with LD_PRELOAD?
    <teythoon> gnu_srs: afaik LD_PRELOAD is ignored by suid programs for
      obvious security reasons
    <gnu_srs> aha, thanks:-/
    <braunr> gnu_srs: what's your problem with suid ?
    <gnu_srs> I made changes to libc and tried them out with
      LD_PRELOAD=... test_progam. It worked as any user (including root),
    <gnu_srs> but not with suid settings. Justus explained why not.
    <braunr> well i did too
    <braunr> but is that all ?
    <braunr> i mean, why did you test with suid programs in the first place ?
    <gnu_srs> to get different euid and egid numbers

    <gnu_srs> hi, anybody seen this with eglibc-2.17-96: locale: relocation
      error: locale: symbol errno,
    <gnu_srs> version GLIBC_PRIVATE not defined in file libc.so.0.3 with link
      time reference
    <teythoon> yes, I have
    <teythoon> but afaics nothing did break, so I ignored it


## IRC, freenode, #hurd, 2013-11-23

    <gnu_srs> Finally 8-)
    <gnu_srs> Good news: soon both SCM_CREDS _and_ SCM_RIGHTS is supported
      jointly. RFCs will be sent soon.


## IRC, freenode, #hurd, 2013-12-05

    <gnu_srs> I have a problem with the SCM_CREDS patch and dbus. gamin and my
      test code runs fine.
    <gnu_srs> the problem with the dbus code is that it won't work well with 
    <gnu_srs> auth_user_authenticate in sendmsg and auth_server_authenticate in
      recvmsg.
    <gnu_srs> Should I try to modify the dbus code to make it work?
    <youpi> unless you manage to prove that dbus is not following the posix
      standard, there is no reason why you should have to modify dbus
    <gnu_srs> I think the implementation is correct,
    <gnu_srs> but auth_user_authenticate hangs sendmsg until
      auth_seerver_authenticate is executed in recvmsg.
    <gnu_srs> and dbus is not doing that, so it hangs in sendmsg writing a
      credentials byte.
    <gnu_srs> well the credentials byte is definitely non-posix.
    <gnu_srs> I found a bug related to the HURD_DPORT_USE macro too:-(
    <youpi> ah, yes, auth_user_authenticate might be synchronous indeed, let me
      think about it
    <gnu_srs> Nevertheless, I think it's time to publish the code so it can be
      commented on:-D
    <youpi> sure
    <youpi> publish early, publish often


# IRC, freenode, #hurd, 2014-01-17

    <gnu_srs> youpi: as a start all our requested dbus changes are now
      committed, and in Debian unstable
    <youpi> good :)


# IRC, freenode, #hurd, 2014-01-30

    <pochu> dbus has some known problems
    <pere> known fixes too?
    <pochu> http://www.gnu.org/software/hurd/open_issues/dbus.html
    <gnu_srs> pochu: Maybe that page should be updated:
      http://lists.nongnu.org/archive/html/bug-hurd/2013-12/msg00150.html
    <youpi> gnu_srs: well, maybe you can do it :
    <youpi> )