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. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
