http://sourceware.org/bugzilla/show_bug.cgi?id=11441

[Dave Brolley]

On 04/27/2010 05:24 PM, Frank Ch. Eigler wrote:
> Hi -
>
> Thanks for assembling the notes and being so patient with feedback.
> Overall it looks fine.  Some quibbles:
>    
Thanks in return for your feedback.
> The proposed command line options are sometimes a bit baroque.  If you
> excuse the bike-shedding,
The proper design for a user interface is hardly bike-shedding...
>   something like
>
>         stap --authorize=[local|global],[add|remove]
> e.g.   stap --authorize=local,remove
>
> looks grammatically paradoxical.  Maybe fork it into
> --add-auth=[local|global] and --del-auth=[local|global].  Also,
> "local" vs "global" are poor names for "this user" vs. "all users".
>
> (It may help to make the option keyword the verb and the parameter an
> object of the verb.)
>    
Something like --add-auth and --del-auth are ok with me. As for 'local' 
and 'global' being bad choices, how about 'user' and 'all'?
> Re. stap --server-status=trusted, how would stap determine the
> trustedness of remote servers?  Do they advertise their ssl/signing
> keys?
>    
As a trusted peer, successfully establishing a ssl connection is 
sufficient. As a trusted signer, I was thinking that the server would 
sign some random chunk of data and that stap would verify the signature 
in the same way that staprun verifies a signed module.
> Re. staprun server searching, I'd rather not go down that road.
> staprun is setuid, and thus by itself argues for minimal function
> rather than growth.
>    
Ok. Given that this is to help unprivileged users find and manage 
suitable servers for signing and the use of --unprivileged in turn 
implies the presence of the client (now part of stap), I guess it's ok 
to limit these capabilities to stap.

I guess this also implies more specific option names for stap in order 
to distinguish what is being authorized:

--add-server-auth=[current|all]
--del-server-auth=[current|all]
--add-signing-auth
--del-signing-auth

> Some suggestions:
>
> The stap --daemon option should support invocation via inetd (i.e.,
> with live sockets on stdin/stdout, with port numbers indirectly
> assigned by sysadmin), as well as a self-serving mode where stap picks
> a port number for itself, optionally advertises via avahi, and loops
> in an accept(2) loop.
>    
Ok. How about --daemon[=inetd] in order to distinguish the two modes?
> The particular constraint of enforcing file size limits on incoming
> request packages might be solved by using an uncompressed packaging
> format such as tar.  Such a change would necessitate consideration
> about backward compatibility (old/new clients/servers trying or
> being prevented from talk to each other).
>    
The packing format can be easily changed. FWIW we already have a 
client/server compatibility issue which was created when we changed the 
wire protocol to have individual files for each client command line 
option. I'll make the sure the solution detects this as well.
> Build-wise, it will be necessary to make all this merged code optional
> based on build-time autoconf tests.  This could complicate the logic
> for stap command line processing even further; the changes will have
> to be tasteful.
>    
Noted.
> The proposal does not address several robustness issues identified in
> section 3, "size of request packages" etc.  While one may assume that
> such issues will be dealt with once stap-server and stap are merged
> together, it would be worthwhile to elaborate as to *how*.  There is
> little reason in principle why those constraints couldn't be
> identically applied in the current stap-server-connect.c code.
>    
Under the heading "Direction" it was stated that "Issues 3 and 5 are 
simply a matter of doing the work and are not directly related to the 
design of the client/server." For all except 3a (the frequency of client 
requests), it would be mainly a matter of deciding on suitable limits. 
For 3a:

o the server could accept and service requests on separate threads and 
enforce a threshold on the frequency of incoming requests or the number 
of requests concurrently being serviced.

o I believe xinetd contains functionality for dealing with DOS attacks 
due to frequency of requests.

Overall, I believe that the other issues are reason enough to consider 
merging components.
> I wonder actually if it would make more sense to merge the *client*
> side into stap first, then see if merging stap-server into stap is
> still necessary.  After all, it is the client side that a normal user
> sees, and automation/transparency at that point would be ideal.
>    
I don't have a strong opinion on which to merge first.
> It would be nice to see a list of all the typical commands remaining
> post-proposal, and perhaps a parallel table listing the status quo.
>
>    
Assuming installation via the systemtap, systemtap-client and 
systemtap-server RPMs:

Current commands                                  Proposed Commands
------------------------------------------------------------------------------------------------------------
service stap-server start                         service stap-server start
service stap-server status                        service stap-server status
service stap-server stop                          service stap-server stop
stap-client ...                                   stap --server ...
stap-client --server=XXX ...                      stap --server=XXX ...
(as user) stap-authorize-server-cert CERTFILE     (as user) stap 
--add-server-auth=user --server=XXX
(as root) stap-authorize-server-cert CERTFILE     (as root) stap 
--add-server-auth=all --server=XXX
(as root) stap-authorize-signing-cert CERTFILE    (as root) stap 
--add-signing-auth --server=XXX
Not Directly Possible                             (as user) stap 
--del-server-auth=user --server=XXX
Not Directly Possible                             (as root) stap 
--del-server-auth=all --server=XXX
Not Directly Possible                             (as root) stap 
--del-signing-auth --server=XXX
/usr/libexec/systemtap/stap-find-servers          stap 
--server-status=online,compatible
/usr/libexec/systemtap/stap-find-servers --all    stap 
--server-status=online
Query Not Possible                                stap 
--server-status=compatible,trusted,signer
Query Not Possible                                stap 
--server-status=online,compatible,trusted,signer

Notes:
- The commands for managing (starting, stopping and querying) local 
servers remain unchanged.

- Currently, hidden (libexec) utilities must be used in order to search 
for remote servers and only online servers can be queried. The proposed 
commands allows for a greater variety of queries and are consolidated 
into stap.

- Currently, a sysadmin must locate the correct certificate file in 
order to authorize a server as a trusted SSL peer or as a trusted 
signer. With the proposed new commands, the certificate is obtained 
directly from the the server itself.

- Currently, server authorization can only be revoked by deleting the 
entire database of trusted servers or by using a tool like 'certutil' to 
remove individual certificates. Revocation is provided for using the 
proposed new commands, but could also be provided by extending the 
existing tools.