Only try to create keyring directory when root
 

On Mon, Mar 28, 2011 at 1:34 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
> If we try and fail to create it, the -e flag to bash will make --help
> and --version break.
>
> Signed-off-by: Ray Kohler <ataraxia937@gmail.com>
> ---
> *scripts/pacman-key.sh.in | * *2 +-
> *1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
> index 89e52fc..057b3bb 100644
> --- a/scripts/pacman-key.sh.in
> +++ b/scripts/pacman-key.sh.in
> @@ -249,7 +249,7 @@ GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR} --no-permission-warning"
> *# Try to create $PACMAN_KEYRING_DIR if non-existent
> *# Check for simple existence rather than for a directory as someone may want
> *# to use a symlink here
> -[[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 755 "${PACMAN_KEYRING_DIR}"
> +(( EUID != 0 )) || [[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 755 "${PACMAN_KEYRING_DIR}"
>
> *# Parse and execute command
> *command="$1"
> --
> 1.7.4.2

Dan, was this not an acceptable means of dealing with the broken
"pacman-key -h"? I see you workshopping someone else's much more
detailed patch for the same issue. I sent mine in immediately on
seeing you report the bug - I don't want it to be said that I don't
fix bugs I introduce.

In any case, if you don't want it for whatever reason, let me know so
I can drop it from my tree.

Only try to create keyring directory when root
 

On Tue, Mar 29, 2011 at 5:21 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
> On Mon, Mar 28, 2011 at 1:34 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
>> If we try and fail to create it, the -e flag to bash will make --help
>> and --version break.
>>
>> Signed-off-by: Ray Kohler <ataraxia937@gmail.com>
>> ---
>> *scripts/pacman-key.sh.in | * *2 +-
>> *1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
>> index 89e52fc..057b3bb 100644
>> --- a/scripts/pacman-key.sh.in
>> +++ b/scripts/pacman-key.sh.in
>> @@ -249,7 +249,7 @@ GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR} --no-permission-warning"
>> *# Try to create $PACMAN_KEYRING_DIR if non-existent
>> *# Check for simple existence rather than for a directory as someone may want
>> *# to use a symlink here
>> -[[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 755 "${PACMAN_KEYRING_DIR}"
>> +(( EUID != 0 )) || [[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 755 "${PACMAN_KEYRING_DIR}"
>>
>> *# Parse and execute command
>> *command="$1"
>> --
>> 1.7.4.2
>
> Dan, was this not an acceptable means of dealing with the broken
> "pacman-key -h"? I see you workshopping someone else's much more
> detailed patch for the same issue. I sent mine in immediately on
> seeing you report the bug - I don't want it to be said that I don't
> fix bugs I introduce.
>
> In any case, if you don't want it for whatever reason, let me know so
> I can drop it from my tree.

Sorry- I forgot to get back to you, but I thought you would pick up on
it from the other conversation. This patch makes --help not break, but
doesn't do it in a way I like. I have a bad taste in my mouth for all
UID-specific workarounds in most pacman code due to this monstrosity:
http://projects.archlinux.org/pacman.git/tree/src/pacman/util.c#n89

-Dan

Only try to create keyring directory when root
 

On 2011/3/30 Dan McGee <dpmcgee@gmail.com> wrote:
> Sorry- I forgot to get back to you, but I thought you would pick up on
> it from the other conversation. This patch makes --help not break, but
> doesn't do it in a way I like. I have a bad taste in my mouth for all
> UID-specific workarounds in most pacman code due to this monstrosity:
> http://projects.archlinux.org/pacman.git/tree/src/pacman/util.c#n89

That's makes me remember a day when I wanted to use pacman to maintain
packages in my HOME on a foreign system. Is it desirable to get rid of
that? That's actually very strange that pacman wants to check such a
thing whereas libalpm doesn't.

Proper write permission checking in libalpm seems to be sufficient
(with good error catching in pacman).

--
Rémy.

Only try to create keyring directory when root
 

On Tue, Mar 29, 2011 at 6:07 PM, Rémy Oudompheng
<remyoudompheng@gmail.com> wrote:
> On 2011/3/30 Dan McGee <dpmcgee@gmail.com> wrote:
>> Sorry- I forgot to get back to you, but I thought you would pick up on
>> it from the other conversation. This patch makes --help not break, but
>> doesn't do it in a way I like. I have a bad taste in my mouth for all
>> UID-specific workarounds in most pacman code due to this monstrosity:
>> http://projects.archlinux.org/pacman.git/tree/src/pacman/util.c#n89
>
> That's makes me remember a day when I wanted to use pacman to maintain
> packages in my HOME on a foreign system. Is it desirable to get rid of
> that? That's actually very strange that pacman wants to check such a
> thing whereas libalpm doesn't.
You haven't been here long, have you? :) pacman and libalpm have a lot
of gotchas like this, as the frontend/backend split was done a tad
oddly way back when. libalpm would eat s**t pretty fast without this
safeguard though, as far as I know.

> Proper write permission checking in libalpm seems to be sufficient
> (with good error catching in pacman).
That's the quick assumption, then you start to peel the layers from
the onion like we've all tried in the past because this problem seems
simple. You forgot:
* ldconfig invocation
* scriptlets and chrooting, even if root is "/" (see commit 5d30c5c0b76e)
* extraction permissions- chown. chmod, etc.
* database locking (commit f4ecc908eccc3a for example)

-Dan