[apparmor] [PATCH 09/20] add helper fn to query file path permissions

[Christian Boltz]

Hello,

Am Freitag, 29. Mai 2015 schrieb Tyler Hicks:
> On 2015-05-30 00:00:25, Christian Boltz wrote:
> > Am Freitag, 29. Mai 2015 schrieb Tyler Hicks:
> > > On 2015-05-29 01:39:15, John Johansen wrote:
> > > > +int aa_query_file(uint32_t mask, const char *label, const char
> > > > *path, +		  int *allowed, int *audited)
> > > 
> > > I prefer that we require 'size_t label_len' and 'size_t path_len'
> > > parameters. The caller may already have the string lengths stored
> > > in
> > > variables, eliminating unnecessary calls to strlen(). Also, it
> > > allows
> > > for non-nul-terminated strings to be used.
> > 
> > You mean you want to call the function with path "foo\0" and
> > path_len
> > 12345?
> > 
> > Personally, I prefer an unnecessary strlen() call over an option to
> > allow someone to hand in invalid data (and, caused by that, possibly
> > doing funny[tm] things) ;-)
> 
> You may not be aware that strlen() requires the string to be
> nul-terminated. If they wanted to shoot themselves in the foot or "do
> funny things" they could just pass in a non nul-terminated string to
> aa_query_file().

I don't know too much about C, but I already heard that strings must be 
\0-terminated ;-) and I'm not really surprised that strlen() needs the 
\0 to find the end.

> Also, libapparmor is in the process' address space. It makes no
> difference if we allow the caller to specify the string length or
> not...

So basically we have to decide if we
a) reduce the number of function parameters, which makes it easier for
   callers, but also means that the string _must be_ \0-terminated
b) have a parameter for the string len, which could possibly come with a
   wrong value

At least for non-C callers (we have perl/python/whatever bindings for 
libapparmor), option a) sounds better to me.

That said - I'll let the decision to you ;-)


Regards,

Christian Boltz
-- 
If Microsoft is the solution, I want my problems back.