[pacman-dev] [PATCH 1/2] [WIP] move wordsplit into ini for sharing
Not technically related to INI parsing, but we use it with INI files.
---
lib/libalpm/hook.c | 113 ---------------------------------------------
src/common/ini.c | 113 +++++++++++++++++++++++++++++++++++++++++++++
src/common/ini.h | 3 ++
3 files changed, 116 insertions(+), 113 deletions(-)
diff --git a/lib/libalpm/hook.c b/lib/libalpm/hook.c
index 6143ea0f..c385b5d5 100644
--- a/lib/libalpm/hook.c
+++ b/lib/libalpm/hook.c
@@ -17,7 +17,6 @@
* along with this program. If not, see http://www.gnu.org/licenses/.
*/
-#include
---
systemvp should pretty much be a drop-in replacement for system with
the exception that it takes an argv array and uses exec. If anybody
wants to play with it to stress test it a little, I have
a self-contained copy and test program at:
https://github.com/andrewgregory/snippets/blob/systemv/c/systemv.c
TODO:
* update docs
* fix debug logging
* should the command be run with PATH lookup (execv vs execvp)?
* Is the use of mmap with MAP_ANONYMOUS okay? MAP_ANONYMOUS is
not POSIX but "most systems also support MAP_ANONYMOUS (or its
synonym MAP_ANON)" (mmap(2)).
* should we reset signals prior to exec'ing like we do with
hooks/scripts?
src/pacman/conf.c | 95 ++++++++++++++++++++++++++++++++++++++---------
src/pacman/conf.h | 2 +
2 files changed, 80 insertions(+), 17 deletions(-)
diff --git a/src/pacman/conf.c b/src/pacman/conf.c
index 2d8518c4..faf446dc 100644
--- a/src/pacman/conf.c
+++ b/src/pacman/conf.c
@@ -26,9 +26,11 @@
#include
--- A few changes I omitted from the initial patch. Does anybody know what usepart was for? It was unset unless %o was used in XferCommand, but I'm not sure what the use case for an XferCommand without %o would be. src/pacman/conf.c | 11 ++++------- test/pacman/tests/sync200.py | 2 +- test/pacman/tests/xfercommand001.py | 2 +- 3 files changed, 6 insertions(+), 9 deletions(-) diff --git a/src/pacman/conf.c b/src/pacman/conf.c index faf446dc..c2b7da43 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -249,7 +249,6 @@ static int download_with_xfercommand(const char *url, const char *localpath, int force) { int ret = 0, retval; - int usepart = 0; int cwdfd = -1; struct stat st; char *destfile, *tempfile, *filename; @@ -322,12 +321,10 @@ static int download_with_xfercommand(const char *url, const char *localpath, } else { /* download was successful */ ret = 0; - if(usepart) { - if(rename(tempfile, destfile)) { - pm_printf(ALPM_LOG_ERROR, _("could not rename %s to %s (%s)\n"), - tempfile, destfile, strerror(errno)); - ret = -1; - } + if(rename(tempfile, destfile)) { + pm_printf(ALPM_LOG_ERROR, _("could not rename %s to %s (%s)\n"), + tempfile, destfile, strerror(errno)); + ret = -1; } } diff --git a/test/pacman/tests/sync200.py b/test/pacman/tests/sync200.py index 2bcdd5d3..18f38b81 100644 --- a/test/pacman/tests/sync200.py +++ b/test/pacman/tests/sync200.py @@ -1,6 +1,6 @@ self.description = "Synchronize the local database" -self.option['XferCommand'] = ['/usr/bin/curl %u > %o'] +self.option['XferCommand'] = ['/usr/bin/curl %u -o %o'] sp1 = pmpkg("spkg1", "1.0-1") sp1.depends = ["spkg2"] diff --git a/test/pacman/tests/xfercommand001.py b/test/pacman/tests/xfercommand001.py index 0d244dc6..0ac99080 100644 --- a/test/pacman/tests/xfercommand001.py +++ b/test/pacman/tests/xfercommand001.py @@ -3,7 +3,7 @@ # this setting forces us to download packages self.cachepkgs = False #wget doesn't support file:// urls. curl does -self.option['XferCommand'] = ['/usr/bin/curl %u > %o'] +self.option['XferCommand'] = ['/usr/bin/curl %u -o %o'] numpkgs = 10 pkgnames = [] -- 2.21.0
On 10/6/19 6:50 am, Andrew Gregory wrote:
Does anybody know what usepart was for? It was unset unless %o was used in XferCommand, but I'm not sure what the use case for an XferCommand without %o would be.
When %o was added, there were cases in the wild where users had a downloader that did not support resuming the download. No sure this would be the case now... Allan
On 06/11/19 at 11:06am, Allan McRae wrote:
On 10/6/19 6:50 am, Andrew Gregory wrote:
Does anybody know what usepart was for? It was unset unless %o was used in XferCommand, but I'm not sure what the use case for an XferCommand without %o would be.
When %o was added, there were cases in the wild where users had a downloader that did not support resuming the download. No sure this would be the case now...
I assume nobody minds if that possibility is removed.
On 10/6/19 6:50 am, Andrew Gregory wrote:
---
A few changes I omitted from the initial patch.
Does anybody know what usepart was for? It was unset unless %o was used in XferCommand, but I'm not sure what the use case for an XferCommand without %o would be.
According to the man page, %o is optional. I'm OK for that to change... Allan
Signed-off-by: Andrew Gregory
Converts an argc/argv pair to a string for presentation to the user.
Signed-off-by: Andrew Gregory
Hi Andrew,
- for(i = 0; i + 1 < argc; i++) { - strcpy(p, argv[i]); - p += strlen(argv[i]); - *p++ = ' '; - }
stpcpy(3)? -- Cheers, Ralph.
On 12/10/19 8:20 pm, Ralph Corderoy wrote:
Hi Andrew,
- for(i = 0; i + 1 < argc; i++) { - strcpy(p, argv[i]); - p += strlen(argv[i]); - *p++ = ' '; - }
stpcpy(3)?
This patch is just relocating that code block. A change to stpcpy would be a separate patch. Allan
system() runs the provided command via a shell, which is subject to
command injection. Even though pacman already provides a mechanism to
sign and verify the databases containing the urls, certain distributions
have yet to get their act together and start signing databases, leaving
them vulnerable to MITM attacks. Replacing the system call with an
almost equivalent exec call removes the possibility of a shell-injection
attack for those users.
Signed-off-by: Andrew Gregory
On 12/10/19 1:45 pm, Andrew Gregory wrote:
system() runs the provided command via a shell, which is subject to command injection. Even though pacman already provides a mechanism to sign and verify the databases containing the urls, certain distributions have yet to get their act together and start signing databases, leaving them vulnerable to MITM attacks. Replacing the system call with an almost equivalent exec call removes the possibility of a shell-injection attack for those users.
Signed-off-by: Andrew Gregory
--- v2: * properly deal with signals * pass errno via pipe instead of mmap * fix debug logging src/pacman/conf.c | 129 ++++++++++++++++++++++++---- src/pacman/conf.h | 2 + test/pacman/tests/sync200.py | 2 +- test/pacman/tests/xfercommand001.py | 2 +- 4 files changed, 116 insertions(+), 19 deletions(-)
diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 2d8518c4..9a39bba9 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -29,6 +29,7 @@ #include
#include #include /* uname */ +#include #include /* pacman */ @@ -153,6 +154,7 @@ int config_free(config_t *oldconfig) free(oldconfig->print_format); free(oldconfig->arch); free(oldconfig); + wordsplit_free(oldconfig->xfercommand_argv);
This line needs to be one higher. A
On 12/10/19 1:45 pm, Andrew Gregory wrote:
system() runs the provided command via a shell, which is subject to command injection. Even though pacman already provides a mechanism to sign and verify the databases containing the urls, certain distributions have yet to get their act together and start signing databases, leaving them vulnerable to MITM attacks. Replacing the system call with an almost equivalent exec call removes the possibility of a shell-injection attack for those users.
Signed-off-by: Andrew Gregory
<snip>
@@ -230,17 +300,26 @@ static int download_with_xfercommand(const char *url, const char *localpath, unlink(destfile); }
- tempcmd = strdup(config->xfercommand); - /* replace all occurrences of %o with fn.part */ - if(strstr(tempcmd, "%o")) { - usepart = 1; - parsedcmd = strreplace(tempcmd, "%o", tempfile); - free(tempcmd); - tempcmd = parsedcmd; + if((argv = calloc(config->xfercommand_argc + 1, sizeof(char*))) == NULL) {
need to free this at the end.
On 10/12/19 at 09:11pm, Allan McRae wrote:
On 12/10/19 1:45 pm, Andrew Gregory wrote:
system() runs the provided command via a shell, which is subject to command injection. Even though pacman already provides a mechanism to sign and verify the databases containing the urls, certain distributions have yet to get their act together and start signing databases, leaving them vulnerable to MITM attacks. Replacing the system call with an almost equivalent exec call removes the possibility of a shell-injection attack for those users.
Signed-off-by: Andrew Gregory
<snip>
@@ -230,17 +300,26 @@ static int download_with_xfercommand(const char *url, const char *localpath, unlink(destfile); }
- tempcmd = strdup(config->xfercommand); - /* replace all occurrences of %o with fn.part */ - if(strstr(tempcmd, "%o")) { - usepart = 1; - parsedcmd = strreplace(tempcmd, "%o", tempfile); - free(tempcmd); - tempcmd = parsedcmd; + if((argv = calloc(config->xfercommand_argc + 1, sizeof(char*))) == NULL) {
need to free this at the end.
Updated patch pushed to my repo that fixes this and the misplaced free and also corrects the indenting in systemvp to use tabs.
On Sun, Jun 09, 2019 at 10:13:55AM -0700, Andrew Gregory wrote:
---
systemvp should pretty much be a drop-in replacement for system with the exception that it takes an argv array and uses exec. If anybody wants to play with it to stress test it a little, I have a self-contained copy and test program at: https://github.com/andrewgregory/snippets/blob/systemv/c/systemv.c
TODO: * update docs * fix debug logging * should the command be run with PATH lookup (execv vs execvp)? * Is the use of mmap with MAP_ANONYMOUS okay? MAP_ANONYMOUS is not POSIX but "most systems also support MAP_ANONYMOUS (or its synonym MAP_ANON)" (mmap(2)). * should we reset signals prior to exec'ing like we do with hooks/scripts?
This issue was assigned CVE-2019-18182. https://security.archlinux.org/CVE-2019-18182 I'm fixing the AVG whenever pacman 5.2 is released if Xfer isn't included. -- Morten Linderud PGP: 9C02FF419FECBE16
On Thu, Oct 17, 2019 at 05:01:46PM +0200, Morten Linderud wrote:
On Sun, Jun 09, 2019 at 10:13:55AM -0700, Andrew Gregory wrote:
---
systemvp should pretty much be a drop-in replacement for system with the exception that it takes an argv array and uses exec. If anybody wants to play with it to stress test it a little, I have a self-contained copy and test program at: https://github.com/andrewgregory/snippets/blob/systemv/c/systemv.c
TODO: * update docs * fix debug logging * should the command be run with PATH lookup (execv vs execvp)? * Is the use of mmap with MAP_ANONYMOUS okay? MAP_ANONYMOUS is not POSIX but "most systems also support MAP_ANONYMOUS (or its synonym MAP_ANON)" (mmap(2)). * should we reset signals prior to exec'ing like we do with hooks/scripts?
This issue was assigned CVE-2019-18182.
https://security.archlinux.org/CVE-2019-18182
I'm fixing the AVG whenever pacman 5.2 is released if Xfer isn't included.
Uh. I might not have paid attention. Eli mentioned on -security Xfer might not be included in the upcomming release, but then anthraxx pointed out it's in master :o Whats the status? -- Morten Linderud PGP: 9C02FF419FECBE16
On 10/17/19 11:04 AM, Morten Linderud wrote:
On Thu, Oct 17, 2019 at 05:01:46PM +0200, Morten Linderud wrote:
On Sun, Jun 09, 2019 at 10:13:55AM -0700, Andrew Gregory wrote:
---
systemvp should pretty much be a drop-in replacement for system with the exception that it takes an argv array and uses exec. If anybody wants to play with it to stress test it a little, I have a self-contained copy and test program at: https://github.com/andrewgregory/snippets/blob/systemv/c/systemv.c
TODO: * update docs * fix debug logging * should the command be run with PATH lookup (execv vs execvp)? * Is the use of mmap with MAP_ANONYMOUS okay? MAP_ANONYMOUS is not POSIX but "most systems also support MAP_ANONYMOUS (or its synonym MAP_ANON)" (mmap(2)). * should we reset signals prior to exec'ing like we do with hooks/scripts?
This issue was assigned CVE-2019-18182.
https://security.archlinux.org/CVE-2019-18182
I'm fixing the AVG whenever pacman 5.2 is released if Xfer isn't included.
Uh. I might not have paid attention. Eli mentioned on -security Xfer might not be included in the upcomming release, but then anthraxx pointed out it's in master :o Whats the status?
Just to clarify, "might not be included in the upcoming release" was before the v2 patch series posted on Friday. Before then, it was unclear if the v1 patch series (which was marked as WIP with some TODO items) would be finished before the upcoming release. This has landed in master as the following commit: https://git.archlinux.org/pacman.git/commit/?id=808a4f15ce82d2ed7eeb06de73d0... And is mentioned in the NEWS file which is prepared here: https://patchwork.archlinux.org/patch/1280/ -- Eli Schwartz Bug Wrangler and Trusted User
On Thu, Oct 17, 2019 at 11:47:58AM -0400, Eli Schwartz wrote:
On 10/17/19 11:04 AM, Morten Linderud wrote:
On Thu, Oct 17, 2019 at 05:01:46PM +0200, Morten Linderud wrote:
On Sun, Jun 09, 2019 at 10:13:55AM -0700, Andrew Gregory wrote:
---
systemvp should pretty much be a drop-in replacement for system with the exception that it takes an argv array and uses exec. If anybody wants to play with it to stress test it a little, I have a self-contained copy and test program at: https://github.com/andrewgregory/snippets/blob/systemv/c/systemv.c
TODO: * update docs * fix debug logging * should the command be run with PATH lookup (execv vs execvp)? * Is the use of mmap with MAP_ANONYMOUS okay? MAP_ANONYMOUS is not POSIX but "most systems also support MAP_ANONYMOUS (or its synonym MAP_ANON)" (mmap(2)). * should we reset signals prior to exec'ing like we do with hooks/scripts?
This issue was assigned CVE-2019-18182.
https://security.archlinux.org/CVE-2019-18182
I'm fixing the AVG whenever pacman 5.2 is released if Xfer isn't included.
Uh. I might not have paid attention. Eli mentioned on -security Xfer might not be included in the upcomming release, but then anthraxx pointed out it's in master :o Whats the status?
Just to clarify, "might not be included in the upcoming release" was before the v2 patch series posted on Friday. Before then, it was unclear if the v1 patch series (which was marked as WIP with some TODO items) would be finished before the upcoming release.
This has landed in master as the following commit:
https://git.archlinux.org/pacman.git/commit/?id=808a4f15ce82d2ed7eeb06de73d0...
And is mentioned in the NEWS file which is prepared here: https://patchwork.archlinux.org/patch/1280/
Ack thanks. That was what anthraxx also wrote to me but the previous mail was sent a bit too quickly. -- Morten Linderud PGP: 9C02FF419FECBE16
On 10/6/19 3:13 am, Andrew Gregory wrote:
Not technically related to INI parsing, but we use it with INI files.
It seems a strange place to put these functions... And they should not have an _alpm prefix if being used outside libalpm. How about putting them util-common without the prefix? Allan
participants (5)
-
Allan McRae
-
Andrew Gregory
-
Eli Schwartz
-
Morten Linderud
-
Ralph Corderoy