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
|
remctl To-Do List
Protocol:
* Add support for running commands as filters, passing standard input
asynchronously from the client. This requires significant
re-engineering of the client loop and should wait for better
configuration since we don't want to do this with every command. It
also introduces out-of-order responses and possible deadlocks to the
protocol. docs/protocol-v4 has an initial draft.
* Add a capabilities command to the protocol so that the client can
retrieve the list of supported commands rather than assuming based on
the protocol version.
* Support locating remctl services via SRV records, probably
_remctl._tcp.<hostname>. This will need linking with a resolver
library that allows SRV queries. libresolv and res_search is probably
the best approach, since that should be portable to any system.
* Modify the server to not allow MESSAGE_COMMAND split in the middle of a
length element and require that commands be split in the middle or at
the end of argument data.
Server:
* Add a way of explicitly specifying the null command or subcommand in
the remctl configuration annd then permit it rather than returning a
syntax error.
* Maximum argument count, maximum data size in MESSAGE_COMMAND, and
inactivity timeouts for commands should be configurable parameters of
the server rather than hard-coded values.
* Support LDAP-based ACLs in addition to file system ACLs.
Probably need to support both entitlement and group-based ACLs.
* Add support for external ACL checking programs. If the program exits
with a zero status, access is granted. If it exits 1, access is not
granted but checking continues. If it exits with any other exit
status, access is not granted and checking aborts.
Ideally, for writing generic ACL checking programs, the program should
get the type and service of the remctl command as well as any
arguments. However, it would also be good to support passing other
arguments into the program as specified in the ACL file.
* Sort the files in a directory before processing them so that the order
is deterministic. Affects both configuration (earlier entries override
later ones) and ACL rules in the presence of deny ACLs.
* Add a timeout for commands after which the server kills the command.
* The server should call gss_inquire_context to retrieve the mechanism
OID and then pass that in to calls to gssapi_error_string rather than
hard-coding the Kerberos v5 OID.
* Add option to mask all arguments.
* Track all the children spawned by remctld in stand-alone mode. On
receipt of SIGTERM or SIGINT, send SIGUSR1 to all children. In the
children, on receipt of SIGUSR1, exit as soon as the current command in
progress (if any) stops running. (SIGTERM or SIGINT directly to a
child should kill it outright.)
* Support masking the argument following a particular string so that the
argument to a particular flag can be masked regardless of its location
on the command line.
* Add server support for persistent child processes that the server
communicates with over a UNIX domain socket. The best protocol for
communication is probably FastCGI, since that will allow the child
processes to be written in a wide variety of languages and take
advantage of existing libraries. This will probably require a new
implementation of the FastCGI server-side protocol.
* In long-running remctld processes, check for configuration file changes
and reload the configuration automatically.
* Consider dropping the client remctl connection when the client's
authentication credentials have expired. Otherwise, remctld
potentially violates the security properties of the Kerberos protocol
by using authenticators beyond their stated lifetime.
* Move the core server protocol code into a library so that one can embed
a remctl server in other programs.
* Clean up the argv generation code for commands in the server.
Client:
* Implement file upload in the remctl client.
* Add readline support to the remctl client for multiple commands to the
same server in the same authenticated session.
* Add an option that prompts the user, with echo disabled, for a piece of
secure data, prompting twice to ensure both times match, and then sends
that as the last argument to the command. This would be useful for
remctl interfaces to change passwords.
* Allow sending the empty command in the command-line client once the
server supports it.
* Allow multiple comma-separated hosts to be specified on the command
line, resulting in the remctl command being run on each host in turn.
Client library:
* The client should ideally not specify an OID for the authentication
mechanism and instead permit GSS-API to negotiate an appropriate
mechanism. It should then call gss_inquire_context to retrieve the
mechanism OID and then pass that in to calls to gssapi_error_string
rather than hard-coding the Kerberos v5 OID.
Go library:
* Incorporate the Go library developed by Thomas Kula.
Perl library:
* Add Net::Remctl::Backend support for obtaining a Kerberos ticket from a
given keytab file before running a command.
* Add Net::Remctl::Backend support for creating a PAG and obtaining AFS
tokens before running a command.
* Add support for per-command help (possibly extracted from the POD
documentation with some additional markup) to implement the help server
configuration.
Python library:
* Revise for better Python coding style.
* Sort out type handling fully and stop being so aggressive about
supporting multiple ways to specify the commands, instead just
requiring an iterable of str or bytes.
* Add enums for streams and protocol error codes.
* Add proper mypy stubs to typeshed and to this package.
* Move API documentation to proper docstrings and use Sphinx to generate
the documentation.
* Fix or drop module version information.
* Use a named tuple for the return value of output().
* Use a dataclass for RemctlSimpleResult.
* Add a Python equivalent to Net::Remctl::Backend.
Ruby library:
* Revise for better Ruby coding style.
Rust library:
* Write one.
Language bindings:
* Incorporate the Go bindings for the client library.
Documentation:
* Remove the description of the version 1 remctl protocol from the
current protocol specification and put it in its own, separate
specification document. Most people will no longer care how this
works.
* Submit the remctl protocol as an IETF Internet-Draft.
* Document conventions for the configuration in the remctld manual.
* Rewrite the documentation and protocol specification as a proper manual
and format it with Sphinx.
Portability layer:
* Refactor getopt to be easier to understand and less deeply nested.
Test suite:
* Incorporate a program that can generate a Kerberos ticket cache from a
keytab and use that for running the Kerberos tests instead of requiring
the user to generate a keytab.
* Add tests to ensure that no child processes of the remctld server are
still running when the test command finishes for cases like
server/timeout or server/invalid where we've previously stranded child
processes for long periods.
Windows port:
* With more modifications, it should be possible to build remctl against
SSPI, the GSS-API-like interface built into Windows, and remove the
dependency on MIT Kerberos for Windows. However, limitations
surrounding realm trusts in the Kerberos implementation in versions of
Windows prior to Vista would make this a less general solution.
Alternately, a separate client protocol implementation in .NET (either
C# or C++) may be easier than trying to build the current source base
on Windows with SSPI.
* Support the remctl server.
Java implementation:
* Integrate the new Java client implementation.
* Integrate the Java build into the rest of the build system so that it
is enabled using an --enable-java flag similar to the bindings, finds
maven and a JAVA_HOME in configure, and does the JAR build in the main
Makefile using maven.
* Java cannot obtain tickets from a ticket cache created using the
k5.conf file included in the java directory using the current MIT
Kerberos on Debian. It has to prompt for a password and get tickets
itself. Figure out why and fix it.
|
