> As a result, a fair amount of bash scripts as well as habit, in fact *relies 
> on the "improperly" configured sudo.

Is there?  I don't see this myself, and can't really imagine why it would be a 
problem.  The only thing that change is the environment, and the large majority 
of scripts don't pass much *data* though the environment.
And even if they did, all it takes is putting `sudo` at the start of the line 
instead of the command, `sudo FOO=bar script` instead of `FOO=bar sudo script` 
-- ok, that means user changing habits, and that's hard.

And apparently Debian changed `sudo`'s default without too much issues, or at 
least I didn't hear about them, so it sounds very possible.

> There is a ton of stuff in Linux (and BSD and Windows) where "improper" 
> eventually became "standard", and tools & apps that consume their services 
> either have to assume "improper" function, or at least be able not fail in 
> the face of it. Like I said before, I've never seen a base of code yet, that 
> consumes lower-level services as a significant portion of it's function, that 
> doesn't have a significant if not majority share of code devoted to working 
> around flaws. Nirvana would be stuff that works as expected. _Whether or not 
> stuff below it works as expected._
>
> I could be wrong and it's just an opinion, but it feels like your response is 
> one of dogmatic ideology, and does nothing to address the world as it is. 
> That's just my reading. I know that's an attractive stance in the open-source 
> world. (And to be fair, there is an important place at the table for 
> hyper-rigid idealistic purity - but it can't be the only voice. We need the 
> inflexible purists hashing things out with the end users. When those two 
> don't talk, things get bad.)

Well, you're kind of right.  I'm reluctant to make a change I don't feel good 
about in Geany for something I don't think is a Geany problem.  If we "fix" 
Geany, there will be `N-1` applications that suffers from the issue.  If `sudo` 
is "fixed", there will be `0`.  If the platform layer we use is "fixed", there 
will be `N - apps_using_glib` (where `apps_using_glib` is guaranteed to be `>= 
1`).

I get that you have the problem with Geany because you use Geany, but if GLib 
"fixes" it, Geany will be "fixed" as long with a long list of other apps.  Plus 
a long list of apps will show a consistent behavior, instead of each using its 
own version of the hack with its own pros and cons.

And yeah, I'm really sad writing apps requires fixing bugs in the platform, so 
I generally try and fix the platform layer when I can.

So… yeah we *could* make a change to get you and few other users happy.  I *do* 
like happy users.  But I'm also reluctant to participate to the hack party 
without trying to improve the situation.

> To answer your question, yes I do have dotfiles owned by root. Most people do 
> if they use dbus or gvfs. I also have a couple of paths put there by 
> installers, apparently incorrectly. ...But...I've broken things before by 
> assuming nothing but me should have ownership in my own directory ;-). 
> Nothing geany-related anyway. Why do you ask?

I don't, and I do use apps using DBUS and GVFS.

And I ask because actually, if you do have files not owned by your user in your 
dotfiles, there's a lot more problems than just Geany.  If a file is owned by 
root, your user won't be able to touch it, resulting generally in not being 
able to save settings, state, history, etc., or worse fail to start because 
realizing something's fishy is going on.

I know several years ago I had that problem with the `nano` editor: it would 
not be able to write its history file after having been used by `root`, and 
would complain at each startup -- and using such a basic editor as `root` is a 
lot more common.
I don't know if they did something in `nano` itself or it just got fixed when 
Debian started to `env_reset` by default though.

Anyway, my points is that:

1. every application writing user config/state files suffers from this "bug" 
unless they have specific handling for it.  There however *are* many ways to 
avoid this without changing applications, addressing the root cause of the 
problem, and most have been suggested here:
  * `env_reset` in `sudo` configuration (pick this one!!)
  * `sudo -H` instead of `sudo`
  * `su -` instead of `su`
  * Otherwise making sure to update environment variables like `HOME`, 
`XDG_CONFIG_HOME`, `XDG_DATA_HOME`, etc.
2. If really `root` user should be sepcial-cased, it should be done lower in 
the stack, like in the [XDG 
specification](https://standards.freedesktop.org/basedir-spec/latest/index.html),
 and then its implementations (like 
[`g_get_user_config_dir()`](https://developer.gnome.org/glib/unstable/glib-Miscellaneous-Utility-Functions.html#g-get-user-config-dir)
 and friends), so it's "fixed" for many people, and not just one application at 
a time.
  And it should still be possible to override it if a power-user really knows 
he wants to mess with its stuff, so the simple hard-coded logic of "if you're 
root, ignore the environment" seems flawed to me.

---
In the end, I'm not strictly against adding a workaround to Geany, given it's 
good enough in every case, and reasonably simple.  It probably would involve 
`getpwuid()` and getting the home directory that way, and it might involve some 
extra trickiness to really be sure we never access `$HOME`/`$XDG_CONFIG_HOME` 
directly then, even through platform code.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1150#issuecomment-247842535

Reply via email to