Re: [pacman-dev] [PATCH v2] pacman: fix possible buffer overflow

2018-10-16 Thread Andrew Gregory
On 09/22/18 at 11:30pm, morganamilo wrote:
> in the function query_fileowner, if the user enters a string longer
> than PATH_MAX then rpath will buffer overflow when lrealpath tries to
> strcat everything together.
> 
> So make sure to bail early if the generated path is going to be bigger
> than PATH_MAX.
> 
> This also fixes the compiler warning:
> query.c: In function ‘query_fileowner’:
> query.c:192:4: warning: ‘strncpy’ specified bound 4096 equals destination 
> size [-Wstringop-truncation]
> strncpy(rpath, filename, PATH_MAX);
> 
> Signed-off-by: morganamilo 
> 
> diff --git a/src/pacman/query.c b/src/pacman/query.c
> index 00c39638..c661fafb 100644
> --- a/src/pacman/query.c
> +++ b/src/pacman/query.c
> @@ -102,7 +102,7 @@ static char *lrealpath(const char *path, char 
> *resolved_path)
>  {
>   const char *bname = mbasename(path);
>   char *rpath = NULL, *dname = NULL;
> - int success = 0;
> + int success = 0, len;
>  
>   if(strcmp(bname, ".") == 0 || strcmp(bname, "..") == 0) {
>   /* the entire path needs to be resolved */
> @@ -115,8 +115,14 @@ static char *lrealpath(const char *path, char 
> *resolved_path)
>   if(!(rpath = realpath(dname, NULL))) {
>   goto cleanup;
>   }
> +
> + len = strlen(rpath) + strlen(bname) + 2;
> + if (len > PATH_MAX) {
> + errno = ENAMETOOLONG;
> + goto cleanup;
> + }
>   if(!resolved_path) {
> - if(!(resolved_path = malloc(strlen(rpath) + strlen(bname) + 
> 2))) {
> + if(!(resolved_path = malloc(len))) {
>   goto cleanup;
>   }
>   }
> @@ -187,11 +193,16 @@ static int query_fileowner(alpm_list_t *targets)
>   }
>   }
>  
> + errno = 0;

No need to explicitly set errno here.  lrealpath should always set it
on failure.

>   if(!lrealpath(filename, rpath)) {
> + if (errno == ENAMETOOLONG) {
> + pm_printf(ALPM_LOG_ERROR, _("path too long: 
> %s/\n"), filename);
> + goto targcleanup;
> + }
>   /* Can't canonicalize path, try to proceed anyway */
> - strncpy(rpath, filename, PATH_MAX);
> + strncpy(rpath, filename, PATH_MAX - 1);
> + rpath[PATH_MAX - 1] = '\0';

This silences the warning, but filename could still be longer than
PATH_MAX, in which case the results will be incorrect.  I think the
best thing to do is treat ENAMETOOLONG the same as any other lrealpath
error, and explicitly check if strlen(filename) >= PATH_MAX instead.

>   }
> -

Please leave this empty line to separate the two blocks.

>   if(strncmp(rpath, root, rootlen) != 0) {
>   /* file is outside root, we know nothing can own it */
>   pm_printf(ALPM_LOG_ERROR, _("No package owns %s\n"), 
> filename);
> -- 
> 2.19.0


[pacman-dev] [PATCH] libmakepkg: fix linting arrays of empty strings

2018-10-16 Thread morganamilo
[[ ${array[@]} ]] will resolve to false if array only contains empty
strings. This means that values such as "depends=('')" can be inserted
into a pkgbuild and bypass the linting.

This causes makepkg to successfully build the package while pacman
refuses to install it because of the unmet dependency on ''.

Instead check the length of the array.

Signed-off-by: morganamilo 

diff --git a/scripts/libmakepkg/util/pkgbuild.sh.in 
b/scripts/libmakepkg/util/pkgbuild.sh.in
index c6f8a82d..b29229a3 100644
--- a/scripts/libmakepkg/util/pkgbuild.sh.in
+++ b/scripts/libmakepkg/util/pkgbuild.sh.in
@@ -60,7 +60,7 @@ extract_global_variable() {
 
if (( isarray )); then
array_build ref "$attr"
-   [[ ${ref[@]} ]] && array_build "$outputvar" "$attr"
+   (( ${#ref[@]} )) && array_build "$outputvar" "$attr"
else
[[ ${!attr} ]] && printf -v "$outputvar" %s "${!attr}"
fi
@@ -144,7 +144,7 @@ get_pkgbuild_all_split_attributes() {
done
done
 
-   [[ ${all_list[@]} ]] && array_build "$outputvar" all_list
+   (( ${#all_list[@]} )) && array_build "$outputvar" all_list
 }
 
 ##
-- 
2.19.1