-
Notifications
You must be signed in to change notification settings - Fork 65
/
NEWS
1329 lines (1004 loc) · 51 KB
/
NEWS
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
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
NEWS/Changelog for Rserve
---------------------------
NOTE: Rserve 1.8 series has many new features, but it has also removed
support for control commands. If you absolutely need them,
please use Rserve 1.7 series and notify me so I can assess
whether they may be resurrected for the 1.9 series. If you don't
know what it means, just ignore this note.
1.8-15 2024-12-10
o The static HTTP/HTTPS handers are now officially supported
so Rserve.http.add.static() is now exported and documented.
Also Rserve.http.rm.all.statics() has been added to allow the
removal of all handlers.
o There were several bugfixes in the handling of paths in the
static http handlers (sanitization was done on the full path
instead of the request part only and separating / are now
inserted where necessary).
o Shorthand arguments --RS-simple-http <path> and
--RS-simple-http-only <path> have been added to the command
line Rserve. They disable QAP and register a static http
handler using the supplied <path> as document root. If
http.port has not been set, it will default to 8080.
Note that the <path> should be absolute since Rserve changes
the working directory to / when daemonizing (or use
--RS-set daemon=no). The --RS-simple-http variant continues
to process other handlers (static or R) while the
--RS-simple-http-only variant will respond with 404 if
the resource is not found (see Rserve.http.add.static()
documentation).
QAP can be re-enabled if desired by subsequent arguments. If
the desire is to only run a HTTPS server then --RS-set http.port=0
can be used to disable the default and then add all necessary
arguments (or a config file) for the TLS part.
o added run.Rserve(background=TRUE) mode which meshes server
processing loop (i.e., the loop which accepts new connections)
and the R session event loop. The function returns as soon
as all the server ports are bound (essentailly immediately).
This allows the server R process to run R code in the main
session after the server was started and thus influence future
client connections. This is currently only supported on unix.
Please note that any changes to the server R session only
affect new connections, not existing ones.
If a function .Rserve.served is defined in the global
environment then it will be called after each new accepted
client connection in the main R session.
Function stop.Rserve() can be used to stop and remove all
servers started with run.Rserve(). Note that all existing
client connections will remain intact.
NB: This functionality is currently considered experimental
and the return value is undefined (currently TRUE on success,
but may return other information in the future to enable more
fine-grained control over the background servers).
1.8-14 2024-02-13
o Windows: use pkg-config if available (many thanks to Tomas
Kalibera for the work on the toolchain!)
o Close listening socket when re-attaching session. (#155)
o Fixes to the sample C++ client.
1.8-13 2023-11-28
o replace sprintf with snprintf even in safe cases to avoid
compiler warnings.
1.8-12 2023-08-17
o added a work-around for buggy libcrypt (first seen in Ubuntu
22.04) which incorrectly uses salt leading to authentication
error if crypt is used even with a correct password. (#192)
o parsing of dates in conditional requests could be off, leading
to fewer 304 Not Modified responses than expected (proxy).
o added experimental built-in feature in Rserve's HTTP(s) server
to serve static files directly (similar to the feature of the
forward proxy). Multiple prefixes can be registered to serve
static content from different paths using the
Rserve:::Rserve.http.add.static() function. Static handlers
are processed before R handers, but they can pass on requests
if the file is not found. Conditional requests are supported.
1.8-11 2022-11-28
o fix possible buffer overflow attacks in WebSockets code (many
thanks to Dane Henshall for performing a security audit!)
o clean up code to avoid mixing 32-bit and 64-bit integers on
64-bit platforms
o enhance `Rserve.eval()` to report the condition object for
error conditions in the `condition` component of the
`Rserve-eval-error` object (#154) and to support custom
calling handlers.
This is done by adding a new argument `handlers` to
`Rserve.eval()` which allows registration of calling handlers
for the duration of the evaluation. The default
is to register an `error` handler which stores the condition
(via `Rserve_set_last_condition`) so `Rserve.eval` can pick
it up and return in the `condition` component. To revert
to previous behavior, use `handers=NULL` which prevents the
registration of handlers.
o Issue a warning if eval/source configuration directive is used
in `run.Rserve()` since they only affect stand-alone Rserve
daemon startup and thus setting them in an R session is likely
a mistake (as the user can run R code directly in the session
prior to calling `run.Rserve()` instead).
1.8-10 2021-11-25
o reduce the size of the authkey (nonce) in CMD_reqKey to
256 bytes such that the payload of CMD_secLogin can fit
into one encryption block (for 4096-bit RSA key). This
improves the nonce entropy size from 50 bytes to 256.
Note that effectively the maximum safe size of the
authentication payload is 206 bytes. Larger sizes can be
transmitted, but should be considered unsafe due to
the second block not including any nonce.
o Prevent replay attacks on non-forked servers using
CMD_secLogin without CMD_keyReq. (Thanks to
Dane Henshall for reporting!)
Deployments relying on CMD_secLogin for authentication
should upgrade to this version to avoid vulnerability.
Note that clients do not have to be updated.
o Respect CPPFLAGS and LDFLAGS from R CMD config
1.8-9 2021-11-05
o move m4 under tools according to R-exts 1.2
o several fixes to QAP encoding/decoding, use R_xlen_t
type for indexing if available (previously Windows
builds used 32-bit index due to long int size limits).
o protection fixes for serialized commands
o remove rsio entirely since it is not used
1.8-8 2021-10-31
o add basic ulog logging for QAP1 even outside of OCAP mode (#169)
o TLS configuration options now check the success of the
operation and will issue a warning if it failed. Most
importantly `tls.key` must succeed in order for the
server to support TLS.
o New option `tls.client` governs the treatment of client
certificates. There are following possible values:
none - does not ask nor check the client certificate
request - request certificate from the client, but
do not check its validity
require - require client certificate, if not present
or not valid, reject the connection
match:... - client's common name must match exactly one
of the listed (comma-separated) names. No spaces
are allowed around the commas.
prefix:... - the client's common name must start with the
specified prefix
suffix:... - the client's common name must end with the
specified suffix
The options `match`, `prefix` and `suffix` imply `require`.
Each of them can be specified only once. However, it is
possible to use up to one each in which case the requirement
is treated as logical "or", e.g.,
tls.client match:foo.bar
tls.client suffix:me.com
will allow both clients `foo.bar` and `foo.me.com`.
NOTE: `none`/`request`/`require` are mutually exclusive. If
more than one is specified, the behavior is undefined
(currently the last one wins but that shold not be relied
upon). All comparisons are case-senstitive (sorry, no regex
support at this point, because we do not want to depend on
PCRE just yet).
If the `tls.client` option is not specified, then the default
behavior is one of `none` or `request`. In that case no attempt
is made to control the TLS behavior so it depends on the SSL
library's default whether it asks for the client certificate
or not, but in either case it is not checked.
NOTE: probably the best way to use the new feature is to use
certificates issued by your organization with
`tls.client require` and `tls.ca` set to the organization's CA
certificate which means you don't need to check client names
and yet no unauthorized client can connect.
o -DULOG_STDERR now correctly produces ulog output on stderr
and ulog output is visible in the debug build
o TLS shutdowns are performed explicitly and sockets closed
(only affects non-forking servers)
o several possible leaks of arguments under error conditions
were fixed
1.8-7 2020-12-17
o proxy: fail with an error if no servers can bind (#152)
o proxy: fail if SSL cannot be initialized
o include err.h SSL header outside of debug mode
1.8-6 2020-06-11
o proxy: handle WebSockets control frames (PING/PONG/CLOSE)
proper.
o proxy: fail with an error if key/certificate cannot be
loaded at start time. Both -k and -c are required to
enable TLS/SSL. Also the proxy will issues an error if -k
is used and SSL support has not been available at compile
time. (#127)
o proxy: linking no longer hard-codes `-lssl` (it effectively
failed compilation when SSL was not available).
o proxy: added -S <host>[:<port>] which allows automatic
registration and de-registation with a server manager
when the service is available (e.g., this can be used
to keep the compute node list up-to-date automatically
when load-balancing via the nginx reverse proxy).
o support large vectors in QAP encoding/decoding
o restore some Windows compatibility - at least to the point
where it compiles. It is still strongly discouraged to use
Windows given how limited the OS is and how it prevents
any sensible use (Windows only supports single-client,
single-thread, cooperative mode - so for toy uses only).
o content-type header entry is lower-cased only up to a
semicolon since trailing options may be case-sensitive. (#149)
1.8-5 2017-03-25
o add support for callback in OCAP idle mode. If the function
.ocap.idle() exists in the global environment and the
configuration option
use.idle.callback yes
is set then that function is called inside each OCAP iteration
after a timeout of 200ms (i.e., if R is idle in the OCAP loop
with no input from any side for at least 200ms).
o control commands are now officially disabled since they never
worked reliably in the 1.8 series after the the rsio re-write.
1.8-4 2015-12-23
o bugfix: when using compute separation on some Linux systems the
death of the compute process may remain undetected. Rserve
now actively detects if the compute process has terminated and
will signal accordingly. The same goes of a compute process
whose parent has died.
o bugfix: make sure headers are correctly terminated when using
forward proxy and R scripts.
o bugfix: static files served by the proxy had duplicate (and
possibly conflicting) content-type headers.
1.8-3 2015-07-20
o add support for the notion of a context object which can be
retrieved/set using Rserve.context() function. If
io.use.context yes
configuration option is set then the context is passed
as-is in OOB console callbacks as the first argument after
the callback name.
Rserve.eval() can also safely set a context object for the
duration of the evaluation which guarantees that any
previous context is restored upon exit - both on error or
success.
o added WebSockets/QAP proxy and HTTP server. It is a
stand-alone program that can be used to separate the R process
from the network to enhance security. typical setup is for the
proxy to listen on an outside port and connect to Rserve on a
local (unix) socket which is restricted to the user running
the proxy.
It is enabled by default and installed into the package's libs
directory along with the Rserve binaries. It is, however, not
installed into $R_HOME/bin. The building of the proxy can be
disabled via --disable-proxy configure directive.
1.8-2 2015-05-20
o fix bug in the WebSockets protocol implementation where frames
over 64kB from the client may be parsed incorrectly.
1.8-1 2015-04-08
o add ulog() R function to allow custom logging from R code
o add "fork here" directive which allows to spawn multiple
pre-forked instances of Rserve which all share the same
memory. The rest of the configuration file is then ignored in
the forked instance while the parent server instance continues
to read on. This can be useful on machines with many cores and
very short requests where the serial fork() time for each
connection is in the order of the computing time. Note that by
design this only works in configuration files and cannot be
used on the command line.
o daemonize only *after* all servers have been bound such the
exit code can be used to detect if Rserve has actually
started successfully
o add Rserve.eval() function to perfrom REPL-like evaluation
o add a new config option to close all stdio file descriptors
(stdin, stdout, stderr) on daemonization:
close.all.stdio enable
For compatibiliy the default is false.
o Rserve will honor --silent command line option (destined for R)
to not print the "Rserve started .." line.
o add support for console input OOB message, enabled via
console.input enable
When enabled R will request input to ReadConsole by sending a
OOB message to the client, expecting back a string to be used
as input to the console. It is only honored if console.oob is
also enabled.
1.8-0 2014-09-03
o new logging mechanism has been added to Rserve. It can
be enabled using the
ulog <path>
directive and uses syslogd-compatible unix socket or UDP
datagram transfer to log events. Currently, only OCAP
events are logged.
o OCAPs can now be tagged with a name
o avoid duplicate symbols by not loading the Rserve dylib
inside an embedded Rserve instance. This avoid issues
of calling the wrong symbols, but it implies that
run.Rserve() can no longer be used from within a
child proces of an embedded Rserve instance (which
you really don't want to do anyway).
o symbols are now registered *before* processing source/eval
directives from the configuration file
o added new option to remove the working directory on
session close recursively - activated by
workdir.clean enable
If not set, the default is to only remove it if it is empty
(on the assumption there are files that will be served beyond
the life of the session).
o added workdir.parent.mode option which specifies the
permissions on the parent directory of session working
directories. The default is 0755. Unlike workdir.mode this one
does not respect the umask (beause it may be shared and thus
may need to include permissions that are otherwise not
granted).
o the data offset field in the QAP header is deprecated and can
be used for message ID if enabled using
msg.id enable
In that mode all responses will copy the message ID from the
request and new requests (such as OOB send/msg) will use
randomly generated message IDs. This allows clients to more
easily track responses for nested commands. Note that this is
backwards-compatible if old clients use the convention of 0
data offset which was the norm (as long as OOB is not used).
o nested evaluation is supported in OCAP mode. This means that
OCcall followed by another OCcall can be processed before the
first call terminates if the R side issues an OOB message in
which case the second OCcall will be nested within the first
call.
o allow expansion of environment variables in the configuration
file, i.e., ${VAR} will be replaced with the contents of the
VAR environemnt variable. This only applies to the right-hand
side of configuration directives.
o added command line argument --RS-set which allows any
configuration directive that is accepted in the configuration
file to be specified on the command line as
--RS-set directive=value
o fix a typo in the "daemon" configuration option which was
looking for "deamon" instead.
o added support for console callbacks. They can be enabled using
console.oob enable
directive and they result in OOB messages being sent on
console I/O operations.
o add a configuration option "shutdown disable" that will
disable the shutdown command. This makes is a bit harder
for unprivileged users to shut down the Rserve instance.
It does not disable the ctrlShutdown command, so users that
have control command access can still issue a shutdown.
Note that this option will eventually become the default
so consider specifically using "shutdown enable" where
CMD_shutdown is still needed.
Note that the shutdown command is not functional in cases
where user switching is performed anyway, so is it only used
for backward compatibility. Only ctrlShutdown is guaranteed
to work.
o add a configuration option "oob.idle.interval" which will
trigger automated OOB send of "idle" command after a
specified interval. Currently it only works with
WebSockets.
o add a configuration option "forward.stdio enable" which
will enable capturing of stdout/err and forward it to
the peer via OOB send messages. Note that this requires
thread support and uses additional file descriptors.
It in currently only available in OCAP WebSockets.
o bugfix: pairlists were incorrecty protected when parsing
SEXPs (qap_decode) in messages from client to server (#16).
1.7-3 2013-08-21
o the handling of server configuration modes has been
inconsistent for some combinations (mostly affected were
combinations involving WebSockets upgrade and OC mode on
HTTP/WS servers). Also the websockets.qap.oc configuration
option has been misspelled.
o HTTPS->WSS upgrade is now supported
o mkdist -i installs the built package, use -c for check
o Windows compatibility has been restored thanks to
David Champagne from Revolution Analytics
1.7-2 2013-08-12
o when uid/gid is changed, create a new tempdir() and set its
permissions as well as the wokring directory's owner to match.
o bugfix: if the first command is not any of the eval family
the Rserve may respond with an additional, spurious error
response
o deamonized server would record incorrect pid when pid.file
is used (i#5). The pid is now removed on clean sutdown.
o added support for keep.alive configuration option - it is
global to all servers and if enabled the client sockets are
instructed to keep the connection alive by periodic messages.
1.7-1 2013-07-02
o remove a spurious character that prevented compilation on Suns
o add OPENSSL_INCLUDES precious variable that can be used to
point to non-standard location of OpenSSL headers
o check the usability of OpenSSL headers before enabling TLS
support
o added the choice of GPLv2 or GPLv2 with OpenSSL linking exception
1.7-0
*** ---- HEADLINE NEWS ----
*** new protocols: HTTP, HTTPS, WebSockets and TLS/QAP
*** added protocol switching (from QAP to TLS/QAP) via CMD_switch
*** The R client was moved to RSclient package
*** New in-session server support with run.Rserve()
*** Out-of-band messages via self.oobSend()
*** user-based uid/gid switch, MD5/SHA1 stored passwords
*** preliminary IPv6 support; RSA secure authentication
*** .Rserve.done global env hook for optiopnal cleanup
*** auth.function setting to allow custom authentication
*** Object-capability mode for hardened, secure services
*** ---- END - see below for details ----
o This is the first release in the new 1.x Rserve series. Many
of the Rserve internals have been re-written or cleaned
up. The original protocol remains the same (so all clients
that worked with Rserve 0.6 will continue to work), but the
suite of available protocols has been extended (see below).
o added support for multiple protocols in Rserve:
** QAP **
this is the original Rserve protocol used in Rserve 0.x
series. It works over TCP/IP and unix sockets. It is
enabled by default and can be disabled using
"qap disable" configuration directive.
** HTTP **
this is very similar to the built-in R http server except that
on unix it forks on connection so it allows parallel separate,
persistent connections. It requires a worker function
.http.request to be defined in the session which will handle
incoming requests. This allows the use of facilities like
FastRWeb without an external webserver. This protocol is
disabled by default and can be enabled by setting "http.port"
configuration directive to the desired port to listen to.
(Also see TLS support below for https server).
The http.raw.body configuration option (default is false which
results in the same behavior as Rhttpd) can be used to force
passing body in raw form to the handler (useful for the
FastRWeb handler which does its own parsing).
** WebSockets **
this protocol is used by HTML5 web browsers for direct access
to R with a persistent connection. This allows implementation
of websites that have a dedicated R session (and could be used
as an R console). There are two subprotocols supported by
Rserve:
-- WebSocket(*, "QAP") --
this is a tunnel for the original QAP protocol through
WebSockets. It requires a browser capable of binary
WebSockets protocol (version 01 or higher). It allows very
efficient data transfer, typically by loading ArrayBuffers
directly into GPU or CPU.
It is disabled by default and can be enabled using
"websockets.qap enable" configuration directive.
(If no subprotocol is specified, QAP is assumed)
-- WebSocket(*, "text") --
this is a very simplistic protocol using plain text frames
to send input to R and output from R directly as text. It
acts essentially as an R console. This protocol works with
any WebSockets implementation including version hybi-00 and
hixie-75/76
It is disabled by default and can be enabled using
"websockets.text enable" configuration directive.
NOTE: The textual WebSockets protocol does NOT provide any
authentication mechanism, so use with extreme care as you
are essentially giving any user with a web browser access to
R and thus to the shell.
In addition to enabling each or both subprotocols, the port on
which the WebSockets server should listen must be specified in
the configuration using "websockets.port" directive, for
example "websockets.port 8080". Alternatively, the HTTP server
can be enabled to allow connection upgrade to WebSockets on
the same port with "http.upgrade.websockets enable"
NOTE: remember that the default in Rserve is to disallow
remote connections, so you may need to use "remote enable" in
order to use WebSockets or HTTP in practice, since the point
is to serve remote machines. Typically, if both QAP and either
HTTP or WebSockets are used, it is recommended to use QAP on a
local unix socket for better access control.
o Rserve now supports SSL/TLS connections on QAP, HTTP and WS
protocols. The TLS key/CA entries are common for all
protocols. The relevant new configuration directives are:
tls.key <private key PEM file>
tls.cert <server certificate PEM file>
tls.ca <CA PEM file issuing the above certificate>
SSL/TLS can be used in several ways: with separate port for
TLS connections or by switching protocol form a regular QAP
connection using CMD_switch with "TLS" as argument. The latter
can be enabled using
switch.qap.tls enable
Enabled switching is advertized by Rserve with the presence
of a "TLS" entry in the ID string. Keys and other TLS entries
must be initialized in order for TLS to be enabled.
Dedicated TLS servers can be enabled by specifying the port
for the corresponding protocol:
qap.tls.port <port> - for Rserve/QAP
http.tls.port <port> - for HTTPS
websockets.tls.port <port> - for WebSockets
(there are synonyms "https.port" for "http.tls.port" and
"tls.port" for "qap.tls.port", however, the *.tls.port
versions are preferred for clarity)
The use of TLS protocols is encouraged where sensitive data
is transmitted or when requiring secure authentication. For
QAP protocol, using TCL/QAP with SHA1 passwords (also new, see
below) is the currently recommended way where authorization is
required. The only drawback is increased CPU utilization
during transfers casued by the encryption and the fact that
TLS-enabled clients must be used. See also RSA secure
authentication (CMD_keyReq + CMD_secLogin) for a different
method if only the authentication step is to be encrypted.
When enabling TLS tls.key and tls.cert are mandatory, tls.ca
is optional to establish CA chain of trust (whether this is
needed depends on the client and the certificate). To generate
a key and self-signed certificate, you can use something like
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr \
-signkey server.key -out server.crt
NOTE: TLS services are started **in addition** to any other
servers, i.e., if you want to enable TLS/QAP only, you have to
set tls.qap.port but also add "qap disable" to disable the
plain Rserve access.
o QAP servers (classic Rserve QAP, QAP/TLS and WebSocket/QAP)
support object-capability (OC) mode in which all Rserve
commands are disabled except for CMD_OCcall. All messages
including the initial handshake are always QAP and the initial
message defines capabilities (here opaque references to
closures) that can be called. This mode can be enabled using
qap.oc enable ## for Rserve QAP and QAP/TLS
websockets.qap.oc enable ## for WebSockets/QAP
In this mode the configuration *must* define a function
oc.init (typically using eval or source configuration
directives) which has to supply OC references that can be used
in calls. If the evaluation of oc.init() fails, the connection
is closed immediately. The use of invalid OC references or any
other commands other than CMD_OCcall results in immediate
connection termination. This allows creation of hardened,
secure services that can disallow arbitrary code execution.
NOTE: this mode is inherenty incompatible with all classic
Rserve clients. The first four bytes of the initial packet are
"RsOC" instead of "Rsrv"
o Rserve can now be started from within an existing R session
using run.Rserve() command. This allows the user to prepare a
session "by hand", run Rserve from within that session and go
back to the session (by shutting down the server or sending an
interrupt). This allows the use of Rserve even without the
presence of libR.
o Rserve now supports out-of-band (OOB) messages. Those can be
sent using the self.oobSend() [one-way] and self.oobMessage()
[roundtrip] functions from within code that is evaluated in
Rserve child instances. OOB messages are not used by Rserve
itself but offer asynchronous notification to clients that
support it (one typical use are WS-QAP1 tunnels to web
browsers that allow status updates as R code is evaluated).
o Rserve accepts additional command line arguments:
--RS-source <file> (same as "source <file>" in cfg file)
--RS-enable-remote (same as "remote enable" in cfg file)
--RS-enable-control (same as "control enable" in cfg file)
o The Rserve package no longer includes the R client. It has
been moved to a separate package "RSclient" so that it can be
used on machines separate from the server.
o There was a bug in QAP storage estimation affecting pairlists,
possibly resulting in buffer overflows. This should be fixed
and an error message will be printed when such overflows are
detected in the future (which hopefully won't happen).
o Bugfix: command line parsing would skip over some arguments
o Passwords file can contain MD5 or SHA1 hash of a password
instead of the plaintext password for non-crypt
authentication. In that case the hash must be lowercase hex
representation with preceding $ sign, so for example user
"foo" with password "bar" would have an entry
foo $62cdb7020ff920e5aa642c3d4066950dd1f01f4d
You can use
echo -n 'password' | openssl sha1
to obtain the SHA1 hash of a password (openssl md5 for MD5
hash - MD5 is probably more common but less secure than
SHA1). This feature makes sure that passwords are not stored
in plain text and thus are safe from local attacks.
o Rserve now has the ability to change uid/gid according to the
user that has been authenticated. The following settings
concern this feature (unix-only):
auto.uid {enable|disable} [disable]
auto.gid {enable}disable} [disable]
default.uid <uid> [none]
default.gid <gid> [none]
The auto.uid/gid directives enable setuid/setgid based on
user's uid/gid. In case no uid/gid is specified with the
username, the default.uid/gid settings will be used. If there
is no uid/gid in the username and no defaults are specified,
the user's authentication will fail. User's uid/gid can be
specified in the passwords file by appending /uid,gid to the
username. If gid is not specified, uid will be used for both
uid and gid. So for example user "foo" (from the above MD5
example) with uid=501 would have an entry on the passwords
file:
foo/501 $37b51d194a7513e45b56f6524f2d51f2
For this to work, Rserve must be started as root. However,
with auto.uid enabled it is safe to do so since Rserve will
prevent any R access until authenticated. You should, however,
use a client capable of secure RSA authentication or use secure
connection such as QAP/TLS as to not send password in
cleartext over the wire.
o Rserve can now be run in a mode where each connection has a
different uid and/or gid such that separate client instances
are isolated. This allows more restricted setup in cases where
instances may not be trusted and need to be sandboxed. The
following configuration directives are associated with this
functionality:
random.uid {enable|disable} [disable]
random.gui {enable|disable} [disable]
random.uid.range {<from>..<to>} [32768..65540]
If random.uid is enabled and random.gid disable then only the
uid of the process is changed. If both are enabled then the
gid is set to match the value of the uid. random.gid cannot be
enabled without random.uid.
To support sandboxing, the permissions on the working
directory can be specified using
workdir.mode <mode>
o If any kind of client-process uid switching is enabled in the
configuration, the permissions on the working directory will
match the uid of the process. Also the working directories are
now named by the process ID to facilitate cleanup.
o Rserve now supports secure authentication even outside of
SSL/TLS. There are two new commands that can be used by the
client:
CMD_keyReq - requests an authentication key from the server
that will be used to perform a secure
login. The kind of the requested key is
specified as a parameter. Currently, only
"rsa-authkey" is supported which returns server
authentication key (authkey) and a RSA public
key which must be used to encode the authkey
and the authentication information (see below).
The RSA key can be compared on the client side
to ensure the authenticity of the server.
CMD_secLogin - secure login. It consists of an encrypted data
stream that will authenticate the user. In the
case of the "rsa-authkey" method, the stream
consists of the authkey and the login +
password, all of which must be encrypted using
server's RSA key.
The RSA key on the server (Rserve) side is specified using
rsa.key <RSA private key file>
configuration file directive. The file is expected to be in
PEM format. You can generate such file, e.g., with:
openssl genrsa -out server.key 4096
where 4096 is the key size in bits. A public key can be
extracted from the private key using
openssl rsa -pubout -in server.key -out server_pub.key
The clients can pre-share the public key by other means to
compare it to the key received from the server as to verify
its authenticity. This will prevent them from sending the
authentication information to rogue servers.
NOTE: if the rsa.key directive is missing, Rserve will
generate a key on the fly when asked for RSA authentication -
although this allows encrypted transmission and thus is safe
from sniffing, it is not safe from man-in-the-middle attacks
where a rogue server intercepts the request and sends its own
public key. Therefore the use of the rsa.key directive is
highly recommended.
The RSA authentication enables the client to a) check the
authenticity of the server (by comparing the RSA public key)
and b) send authentication information encrypted. This method
is highly recommended in cases where a full TLS/SSL encryption
of the entire connection would be too expensive (i.e. in cases
where the data is large and the security of the transported
data is not crucial).
o Rserve has a preliminary IPv6 support. Rserve must be
installed with --enable-ipv6 configure flag to enable it in
the Rserve build. In order to start all servers on IPv6 add
ipv6 enable
to the configuration file. The option is global, i.e. once
enabled it applies to all servers that support it. Note that
not all features work with IPv6 yet - detaching sessions
(they will use IPv4 for re-attach) and remote client filtering
only work with IPv4 at this point.
o Rserve now binds only to the loopback interface in
"remote disable" mode. This is safer and prevents remote DoS
attacks. Previously, Rserve would bind on all interfaces and
check the peer IP address. If desired, you can replicate the
old behavior by adding
remote enable
allow 127.0.0.1
to the configuration (if you don't know the difference then
you don't need this -- if you actually need this, then you
probably want to add more "allow" entries for the machine's
other interfaces as well).
o If a function .Rserve.done() is defined in the global
environment, it will be run after a clean connection
shutdown. This allows custom code to be run when a client
connection is closed.
o If a function .Rserve.served() is defined in the global
environment of the server, it will be run after a client
connection has been served. For forked servers this is just
after the fork(), for co-operative servers this is after the
client conenction has been closed. It is guaranteed that no
other client is served before the call so it can be used to
manage resources that are unsafe to share with forked
processes (e.g. sockets etc.).
o The server and client process can be tagged with extra
information in argv[0] so it is possible to distinguish the
server and children. This behavior can be enabled using
tag.argv enable
Note, however, that this not always possible and it will have
impact on programs that use argv[0] such as killall.
o Added configuration option pid.file and command-line option
--RS-pidfile which instructs Rserve to write its process id
(pid) into that file at startup.
o Added configuration directives http.user, https.user and
websockets.user which take a username and perform
setuid/setgid/initgroups immediately after forking.
This minimizes the amount of code that is run with
elevated privileges in cases where user switching is desired.
o Added configuration directive
daemon disable
which can be used to prevent Rserve from daemonizing. It has
effect only in builds of Rserve that support daemonization.
Note that -DNODAEMON build flag disables daemonization
entirely and can be used in any Rserve version.
o All commands based on eval now also accept DT_SEXP in addition
to DT_STRING. In such case the parse step is skipped and the
expression is evaluated directly. The intended use of this
functionality is to evaluate language constructs and thus
allow calls with both reference and inlined arguments.
o QAP decoding is slightly more efficient and avoids protection
cascades. QAP_decode() has now only one argument and it is
guaranteed to not increase the protection stack when returning
(which implies that it is the responsibility of the caller to
protect the result if needed).
o Both QAP encoding and decoding now use native copy operations
on little-endian machines which can increase the speed
considerably when the compiler cannot do this optimization
on its own (most commoly used compilers don't).
o Assigning logical NAs now uses the proper NA_LOGICAL value
that is also recognized by R. (PR#276)
o Forked child processes will now close all server sockets so
that any server can be restarted without closing existing
children.
o Signal handling has been streamlined: the server process
captures HUP, TERM and INT which will lead to clean
shutdown. Child processes restore signal handlers back to R so
that regular R signal handling rules apply. Note that
interrupt during eval will result in RESP_ERR with code 127
even if try() is used.
--- In order to support new ideas a major re-organization of Rserve ---
--- has been started - almost 10 years after the first release. ---
--- It is time to look ahead again with a new major version. The ---
--- protocol will remain compatible so 1.x series can be used to ---
--- replace the previous 0.x series ---
0.6-8 2012-02-20
o added RSserverEval() and RSserverSource() control commands
in the R client as well as ctrl parameter to RSshutdown().
o added new facility that allows R scripts running in Rserve to
issue control commands if allowed. This feature must be
enabled in the Rserve configuration file using
r-control enable
This will make self.ctrlEval() and self.ctrlSource() functions
available to code that is running within the Rserve
instance. It is also possible to use this feature without
explicitly loading the Rserve package via
.Call("Rserve_ctrlEval", paste(text, collapse='\n'))
.Call("Rserve_ctrlSource", as.character(file))
although this may change in the future.
0.6-7 2012-01-17
o fix processing of login information
**IMPORTANT**: this fixes a serious security hole in the
remote login mechanism! If you rely on authentication,
please make sure you update your Rserve immediately!
(Thanks to Daniel Faber for reporting)
o add a namespace to make R 2.14+ happy
o work around broken readBin() in R 2.14.0 that errors
on unsigned integers (affects R client only)
0.6-6 2011-12-10
o fix a bug that can cause heap corruption due to incorrect
addressing in padding of symbols. Unless extremely long symbol
names are used it is unlikely to have a real effect in
practice, but in theory it could be used to zero targetted
parts of the heap. Thanks to Ralph Heinkel for reporting.
o fix Rserve() call on Windows with quote=FALSE and more than
one argument.
o clarify that sisocks.h is under LGPL 2.1 as well as the other
headers used by clients.
o add support for plain S4 objects (S4SEXP) in assignments
(Note: derived S4 objects - those using other native SEXP type
as a base - cannot be supported properly, becasue there is no
way to distinguish them from S3 objects!)
o Unsupported types in CMD_assign will no longer crash R.
The resulting object is always NULL and an error is printed on
the R side.
0.6-5 2011-06-21
o use new install.libs.R custom installation script in R 2.13.1
to install binaries
o install clients by default on Windows as well
o multi-arch binaries are no longer installed with the arch suffix
in the package root. The canonical place is libs$(R_ARCH) instead.
For now Rserve.exe/Rserve_d.exe are still installed in the root
but they will be also removed in the future as they are not
multi-arch safe.