`sudo -Es` shell doesn't respect configuration

[voidus]

My ~/.githudrc:

> cat ~/.githudrc
run_fetcher_daemon=false
git_repo_indicator=  

Entering a privileged shell in a git repository using sudo -Es still launches githudd

[gbataille]

I'm guessing it's because you don't have a .githudrc in you root user $HOME. that would be the home used by the system when running with sudo wouldn't it?

[voidus]

It's not quite that simple

voyd@boop> sudo -E bash -c 'echo $HOME'
/home/voyd

the -E preserves the environment, but as far as I can tell, githud actively retrieves the effective user id and looks in their home, which I would argue is not a good approach.

But I'm really trying to highlight the problem here. My git server requires additional active authentication (I basically get a popup whenever I try to push or pull) and that makes my computer practically unusable once githudd starts.

[gbataille]

oh, ok. had never come across -E

I think I see. So if I summarize

• githudd is not a workable solution in your environment. That however has been fixed by your 2 PRs, am I right? (I still need to do a proper release of that)
• sudo -Es creates a second instance, which you think it should not. To which I guess I agree but I don't know if it's really a big deal for most users.

[gbataille]

@voidus I have release 3.3.0 on hackage

[voidus]

I'm personally running githud with a patch that changes the default to not start the daemon and that works for me, but I think I won't be the only person with an issue like this...

Would you be open to making the daemon configurable by a command line switch? That way, the configuration would always be the same regardless of the user context, which I think is what most people would want?

[gbataille]

Ah yes ok I see. The config file is problematic to you because of how I choose where to source it from. Got it. Then I would agree with a command line param. I guess the best would be one to force the location of a config file (rather than me forcing home). Then I would just default to home. I’ll try to look into it

On Sun, 23 Oct 2022 at 16:17, Simon Kohlmeyer ***@***.***> wrote: I'm personally running githud with a patch that changes the default to not start the daemon and that works for me, but I think I won't be the only person with an issue like this... Would you be open to making the daemon configurable by a command line switch? That way, the configuration would always be the same regardless of the user context, which I think is what most people would want? — Reply to this email directly, view it on GitHub <#40 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIPX2MHABALIC47ANWEPP3WEVCI5ANCNFSM6AAAAAAQ2U7AWE> . You are receiving this because you commented.Message ID: ***@***.***>

-- Greg

[voidus]

Would you be interested in contributions on that? If yes, I'd write a separate issue outlining the approach before I start coding.

IIRC there's a library that allows config values to come from a config file, environment variables or CLI args, later overriding previous values, that seems cool.

I was thinking about --config-file but that could run into permissions issues, right? Anyways, that would be a discussion for the other issue.

[gbataille]

Feel free ;) I would be happy not to do it myself ^^

On Mon, 24 Oct 2022 at 16:13, Simon Kohlmeyer ***@***.***> wrote: Would you be interested in contributions on that? If yes, I'd write a separate issue outlining the approach before I start coding. IIRC there's a library that allows config values to come from a config file, environment variables or CLI args, later overriding previous values, that seems cool. I was thinking about --config-file but that could run into permissions issues, right? Anyways, that would be a discussion for the other issue. — Reply to this email directly, view it on GitHub <#40 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIPX2OX3CE3AN6D7H26AADWE2KRJANCNFSM6AAAAAAQ2U7AWE> . You are receiving this because you commented.Message ID: ***@***.***>

-- Greg