Proposition for new remctl ACL scheme / group support
Russ Allbery
eagle at eyrie.org
Sat Apr 5 19:56:24 EDT 2014
Jeffrey Altman <jaltman at secure-endpoints.com> writes:
> On 4/5/2014 3:34 PM, Russ Allbery wrote:
>> The only other thing that I'm not sure about is how annoying it is to set
>> up and tear down the libraries that let you do PTS queries. I'm pretty
>> aggressive about making sure that the remctl server is entirely clean
>> about memory allocation and free and not leaking file descriptors to child
>> processes, and the OpenAFS libraries often have some difficulties there.
> If you want to be able to load and unload the libraries then you cannot
> link to anything that includes OpenAFS rx. rx will start background
> threads and those threads cannot safely be stopped using the OpenAFS
> implementation.
I don't need to be able to unload the libraries. (In general, I'm not a
fan of trying to unload libraries.)
I think the requirement is that the remctl server not leak any file
descriptors to its child process (and obviously not leak threads or memory
so that it can't run for long periods of time). I would strongly prefer
that the remctl server also free all allocated memory before it exits,
since it makes my QA process much easier. However, if that's simply not
possible for a particular ACL scheme, good valgrind suppressions are
probably an adequate substitute.
Note that I do require the ability to run valgrind to verify memory
management in the remctl server. I don't think the OpenAFS libraries make
use of valgrind impossible any more, but if they still do, that will be a
problem.
--
Russ Allbery (eagle at eyrie.org) <http://www.eyrie.org/~eagle/>
More information about the Kerberos
mailing list