Re: setfiles and restorecon performance patch

[Joshua Brindle <jbrindle@tresys.com>]

Russell Coker wrote:
> On Wednesday 04 January 2006 02:55, Steve G <linux_4ever@yahoo.com> wrote:
> 
>>>@@ -143,7 +141,7 @@ int restore(char *filename) {
>>>    if (verbose>1)
>>>      fprintf(stderr,"Warning! %s refers to a symbolic link, not
>>>following last component.\n", filename);
>>>    char *p = NULL, *file_sep;
>>>-    char *tmp_path = strdup(filename);
>>>+    char *tmp_path = strdupa(filename);
>>>    if (!tmp_path) {
>>>      fprintf(stderr,"strdup on %s failed:  %s\n",
>>>
>>>>filename,strerror(errno));
>>
>>Do you need to check for NULL on strdupa calls? If so, the error message
>>needs to have the function updated, too. Otherwise this can be deleted.
> 
> 
> Not sure.  The alloca() man page says that the failure result is undefined but 
> the strdupa() man page says nothing (implies that it's the same as strdup()).
> 
> Ulrich?
> 
> 
>>>@@ -155,14 +153,16 @@ int restore(char *filename) {
>>>      file_sep++;
>>>      p = realpath(tmp_path, path);
>>>    }
>>>-    if (!p || strlen(path) + strlen(file_sep) + 1 > PATH_MAX) {
>>>+    size_t len = strlen(p);
>>>+    if (!p || len + strlen(file_sep) + 2 > PATH_MAX) {
>>
>>What if realpath returned NULL? strlen is using a NULL pointer and then p
>>is checked in the second line to see if its NULL.
> 
> 
> Fixed that, attached a new patch.

strdupa man page says it's a GNU extension, does this work on BSD? We 
should not be making non-portable changes to libraries as SEBSD has the 
potential to catch up and start using these new libraries.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.