[36013] in Kerberos
Re: Proposition for new remctl ACL scheme / group support
daemon@ATHENA.MIT.EDU (Russ Allbery)
Sat Apr 5 19:56:36 2014
From: Russ Allbery <eagle@eyrie.org>
To: Jeffrey Altman <jaltman@secure-endpoints.com>
In-Reply-To: <53409526.2000802@secure-endpoints.com> (Jeffrey Altman's message
of "Sat, 05 Apr 2014 19:43:34 -0400")
Date: Sat, 05 Apr 2014 16:56:24 -0700
Message-ID: <87siprxrdj.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Jeffrey Altman <jaltman@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@eyrie.org) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
