Domain socket error: Not working via sudo is a geany bug, not a feature or bug in sudo #1150
Comments
|
As I reply everyone raising this "bug", get a properly configured Anything that would lead to another user (including root) to writing in a user's home directory should be avoided. If you did write there as root, the user would be left with root-owned file in his home, files he couldn't modify. That's not a good thing. And while I don't want special code for handling If you really want us to change something, you'll need to detail why you'd need inheriting the environment (including If "many other GUI tools" work, it might be for a number of reasons, one possibly being that they use DBus (anything using dconf comes to mind), which may or may not use Out of curiosity, do you have root-owned stuff in your dotfiles? I'm not closing it just now, but I still do consider this invalid at least for the moment |
|
(FTR, we put the socket inside whatever the GLib give us with |
|
@doublemeat as #294 sat for a year before it was closed during one of the regular issue pogroms shows that none of the regular Geany developers or contributors has the need/interest to address this. If you feel you have a use-case, remember, that suggests it is your use-case, not anybody elses. On that basis you would be more likely to succeed if you presented a small, simple, well written and documented pull-request rather than trying to persuade others it is their problem. (Or use the workarounds like -c or different sudo configuration) |
|
This happens on Ubuntu 16.04 if you have an existing instance open. Doesn't happen if you fire up a new instance (using |
|
Thats three workarounds, seems reasonable to close. |
It seems weird that we're putting a socket file in a config directory. We should probably use |
|
Actually we put it in app->configdir so its either the default config dir or overridden by the But the default could be either place IMO (and they are the same on Windows anyway). |
I'm no XDG/LSB expert, but I don't think runtime objects like sockets are supposed to go into a config file directory. |
Maybe, but it's mostly irrelevant to the OP's point, because either way it'd be in the same place as the user's one. Also, while indeed it sounds like a socket is a good candidate for a runtime directory, it would make it harder for us as we -- for the moment -- still want to let the user change it ( |
Indeed, I was just noting it since you mentioned the socket being in the config dir.
Why does the user care where some runtime Unix socket file node is? I agree it's probably not worth changing much at this point though. A (non-portable) solution that could solve this issue would be to detect the presence of and use the |
Looooooooooooooooooooooong term, as in when we drop gtk2 support (since application is since 3.0). |
He doesn't directly, but it has to be different to allow separate instances/config as they are now. So until we have proper single instance, we should have multiple sockets. |
Yeah, each instance would need a uniquely named handle, but that's pretty simple (temp filename, incremented counter filename, etc). As a side note, there's already a unique name for the socket file, at least here, the socket file in |
Thats because the tmpfile is unique, but its semi-random, and therefore it is not discoverable when a geany wants to see it its the first instance, but the link is discoverable since its not random. |
|
Most tmpfile implementations I've used (including GLib IIRC) allow specifying a prefix and/or suffix, something like |
|
It is called geany_socket. but that doesn't help picking the right one when there are more than one. |
|
I meant like geany_001_<rand>.socket, geany_002_<rand>.socket, geany_003_<rand>.socket, etc. |
|
how does that help? How does a new geany decide it should talk to |
|
I guess it doesn't help with this specifically (more multi-session support), but in any case you can still generate a random-ish temp file that is discoverable (removing the need for the link in |
|
Actually the socket has to be config specific, if |
I don't argue that, just that putting a virtual socket file mixed in with the textual config files is weird. |
|
Pull requests with better solutions are welcome :) |
|
Note to future implementor: the socket filename could be in Examples:
And so on. |
|
@elextr thanks for responding. I should comment on something you said, which I think gets to the heart of the matter:
Answers to your two questions:
No one working on geany getting paid, presumably, but there is a reason you do this, right? I don't know what those reasons are, but I know I for one like to have more and more satisfied users. At least, that drives me and studies show drives many other open-source developers. You guys made one of the best lightweight editors around. It just seems such a shame to lose users for no good reason - and in fact for a pointlessly, rigidly dogmatic reason. You can blame it all day long on the sudo program, but the bottom line is there are close to a dozen similar editors - just that I know of first-hand - that don't exhibit this behavior. (In fact no other editor I've tried, period.) Working around underlying bugs in the stack that we have no control over is an inevitable part of developing software. I'd wager half of any code base that consumes underlying services is doing just that. Refusing to do so doesn't make it any less of your bug, because it still affects your users. It doesn't affect "just" me. If you google this problem you'll get back pages of very specific results pointing to countless user forums. Like I said, you guys are volunteers (presumably) doing fantastic work. I can't be "upset" at some of these responses that don't "get it". (Get it? Gedit?). And by "get it", I mean from the perspective of their users who don't care that it's a bug in one of the most commonly used programs in all of *nix, or care about c domain sockets, nor worry about how a temp file shouldn't exist in a user profile directory. All that means is that some of your users can't sudo geany and will have to find a different editor, and most of the time you'll never hear about it. Trust me, I understand that breaking time-honored conventions can cause more problems for everyone now and down the road. I'm not suggesting the solution is that you store a temp file in a user configuration directory. But isn't this seemingly "intractable problem" why c library functions like mktemp exist? Thanks guys. While I'm set for now with a different editor, I'm sad to see geany go from my workflow, and will check back once every several months or so to see if I can, as a test case:
|
|
@doublemeat thank you for continuing to contribute. Your two numbered points:
The problem only exists if users don't use one of the published solutions. Saying "use a specific command line option" is not dogma when so far nobody has a solution that will still support Geanys current feature set, which as it is a lightweight IDE, is more complex than other plain editors. A number of the contributors to Geany do so to support its use as a software development tool rather than a simple editor, (and I'm one) so their focus is on those features, not what they consider (wrongly in your opinion, but they disagree) a minor plain editor usage which has several workarounds. And several contributors have expressed the opinion that they won't ever use a full GUI IDE as root because its too risky, so they won't be fixing it. It isn't clear if gedit supports specifying which of multiple instances to use.
If you persuade somebody to make a PR have them read the comments above, that point out why that doesn't work. To reiterate, part of a mktemp name is variable so multiple temp files with the same base can be present. But as it starts, an instance of Geany has to look for a particular socket, not just any socket, so a name that is variable isn't any use. Other issues around using the chosen config are also noted above. |
|
@elextr Thanks for the thoughtful response. I did actually use Geany for Javascript and Bash script development. Mostly bash. (And system config file editing. Fstab, apt sources, interfaces, etc.) And also as an omnipresent notes app. I have two really useful scripts that conditionally launch editors various ways. The two most useful tools I think I have. I know others who do similar things. One script opens up a specified file normally with nano, if the user is in a terminal and there is no GUI environment available. But if there is a GUI environment available (whether in a terminal or not), it launches (formerly Geany). The other one is even more handy, it's for opening a file via gk/sudo. If launched from a terminal window, it prompts for sudo if necessary. Then if there is a GUI, it used Geany via sudo to open the file. If no GUI, nano. This is a huge time-saver when editing multiple files sequentially with sudo, to avoid typing in password every time. If it is not invoked from a terminal (e.g. "run" dialog), then it gets sudo via gksudo. I can't imagine setting up new systems or administering existing ones without this. (And I'm not a fan of leaving a terminal open via sudo bash, but even if I did the same problem would exist.) So, maybe that helps illustrate a good use case, or maybe not. But either way, I'm left with the question: Why do the half-dozen other "lightweight" editors not suffer from this problem? What/how are they doing different? When I run any of them with sudo and then regularly, at the same time, regardless of order, there is no conflict and no anomolies of mixed-up states. I'm not even sure what you need a "socket" for in the first place, or why you call it that. (Presumably this isn't a TCP socket?) I'm guessing it's just a temp file having something to do with maintaining state. I'm assuming that's my own lack of knowledge of some established architecture paradigm you are using, and although I am genuinely curious, I can't imagine anyone losing sleep over me not knowing. If you really are just using it to maintain state, why not just do so in memory and let OS-level paging take care of "physical instantiation"? And why does Geany need to know where this socket is at startup? Why can't it instantiate a tempfile at startup? So what if there are multiple temp files, possibly unused ones stacking up in the case of unclean Geany shutdowns? (That's a big reason why some /tmp directories map to RAM, and almost all are deleted at startup.) Again, I'm not expecting an answer. We're all busy. I'm just curious. |
|
One more question/idea - how hard would it be to just check for a userid of 0, but a home directory of [not /root]? And in that case, just go ahead and use whatever $HOME says, but add "root" somewhere in the name (or something like that)? I mean, I get it that sudo is broken in that regard. But it will probably never be "fixed" because too much relies on it's very specific behavior. So why not just work with it? There's quite a bit that can be known about the environment we're running in and how we got there. Why not use it, to address the problem of propagating a very well-known and understood bug in a lower level, up to higher-level users? Granted I'm probably mixing up the specific locations you use. (I actually recall the "domain socket" files existing in /tmp, not /home/user. But the same concept would apply.) This would give you a predictable starting location and name, while also allowing geany users to not be inconvenienced by the very inconsiderate sudo bug. I know for a fact from Google that I'm not the only user that experiences this, but even if it were - say, five users, and the fix was literally a 15 minute change to a few lines plus some testing...wouldn't that be satisfying? |
|
@doublemeat I suspect that the nitty gritty details need to be described.
Since you are running from a script, using extra command line options should be no problem. Are you sure that you can't find a combination of options here that makes your root instance suitably separate from a preceding user instance? Using Note also that Geany rolls its own here because of its unique requirements, its ability to work on windows as well, and its independence of the various incompatible session management mechanisms used by different distros. [1] technically the socket is created in /tmp with a unique name, but a link with a known name pointing to the temporary is placed in the config dir. The link is what Geany looks for. |
|
Interesting. Grateful that you took the time to explain, and hopefully it will help others understand as well. It also helped that you pointed out that this needed to work across distros and platforms. I didn't even know Geany ran on Windows. And I do get the "domain socket" communication endpoint concept now, and why it must be known before any one instance of Geany even starts. Ultimately, it boils down to a single feature or requirement, and how it relates to a second, more fundamental requirement: 1) Open new files not in a new Geany instance, but in a new tab in the same instance. And 2) Work the same way across distros and platforms. If you ditched the first requirement, the problem could disappear. (Not that it's a bad requirement. It's a good requirement I think. And not that there aren't other ways to mitigate the problem while keeping both feature/requirements. But for me, personally - and I'm sure I'm in the minority on this specific point - I'd rather it work with sudo and not sudo at the same time, and open single-file multiple instances. If that was the only choice.) So, to make Geany work as designed but also accommodate the sudo bug, I could update my scripts - really just one - to detect when user id = 0, and use one of the flags to point it to a unique or just different pre-known instance. I could even just write a wrapper script called "geany" and put it first in path. For *nix (presumably Windows doesn't have this problem):
But if I can do it that succinctly in a script, could it be nearly as simple in code? (I mean, I know it could be exactly that simple, but in reality probably isn't due to related code existing in different places, and also cross-platform concerns - I'm only worried about two, and a third environment [Windows] doesn't have the problem.) Here's a way to conditionally check for OS in makefile. But again, it doesn't have to be that complex - just two of those tests ("linux" and "darwin") would cover an overwhelming swath, and almost all the rest would be Windows (already OK without anything extra). Anything else not covered, would just experience the bug, but would solve the problem for, perhaps, 99.9% of your users. Perhaps much more simply, the install script could test for the existence of "bash" in the path (and that we're running on a unix-like machine, such as checking for the existence of $MACHTYPE being populated with anything), and if so, name the binary /usr/bin/geany-bin and the bash script above to /usr/bin/geany. (Or create a symlink in /usr/bin to the script instead of binary, etc.) Just some thoughts. |
|
@b4n, thanks for the response. Your response of
may be a technically correct response, but it dismisses reality. The overwhelming majority of installed *unixes - and in fact the majority of cloud computing - ship by default with a not "properly configured sudo". (Ubuntu.) As a result, a fair amount of bash scripts as well as habit, in fact relies on the "improperly" configured sudo. 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.) The world as it is contains a fair amount, possibly a majority, of improperly configured sudo. The world as it is includes a fair amount of people that invoke GUI tools from command-line sudo. To deny either reality, or say we shouldn't or aren't going to recognize their existence, is a fundamental failure. /soapbox 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? |
|
You could probably also make an alias like |
|
For the information of people who read this issue in the future. It is mentioned above that some developers won't use Geany as root because of the risks. But it was not explained what the risk is. The risk is because, as Geany is an IDE, it has the capability to run random commands, and as it has a plugin interface, it can run random code. If a root instance of Geany was to use the user configuration it could run, as root, commands or code installed as user. This could be any rubbish a user was experimenting with, or it could be malicious code installed with user privileges. Running user code as root is an archetypal privilege escalation attack. |
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 apparently Debian changed
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 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.
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 Anyway, my points is that:
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 |
|
Hum, just reading the documentation of |
|
…or not, not sure. S/a https://sourceforge.net/p/geany/bugs/471/ |
This tries to determine whether the default configuration directory is owned by the calling user, and falls back to a directory under that user's home directory if not. This doesn't solve the case where the first run would create the directory in another user's home, but on the other hand handles any combination of actual user and environment, not only root. This however also doesn't work if the user is expected not to actually own the files in hist home directory but e.g. only is part of the group and still has write privileges. Closes geany#294. Closes geany#1150. Closes https://sourceforge.net/p/geany/bugs/471/.
|
Possible "fix": |
|
@b4n, and what about |
|
@elextr if the user specified |
|
( Line 578 in 8e27b27 |
|
@b4n, its ok, I read your hack wrong, its user configs only :) |
This tries to determine whether the default configuration directory is owned by the calling user, and falls back to a directory under that user's home directory if not. This doesn't solve the case where the first run would create the directory in another user's home, but on the other hand handles any combination of actual user and environment, not only root. This however also doesn't work if the user is expected not to actually own the files in hist home directory but e.g. only is part of the group and still has write privileges. Closes geany#294. Closes geany#1150. Closes https://sourceforge.net/p/geany/bugs/471/.
There are good reason for running geany via sudo, as opposed to gksudo.
I'm aware of bug #294, and why this happens with sudo and not gksudo. (In short, because gksudo sets $HOME to /root, while sudo leaves $HOME to same as user - and if user is already running geany in their user session, an attempt to open the same config file will be made, and fail).
Please allow me to explain why this shouldn't be dismissed as "not a bug", just because there is a workaround. The problem is not just that sudo works differently than gksudo. The problem is that, and Geany's flawed implementation of config file (or "domain socket" or whatever is going on with that file).
Like many Linux administrators / power users, I use GUI tools with sudo very often, for three related reasons: 1) I prefer working in a terminal; 2) I prefer GUI terminals for ease-of-use [e.g. highlight/copy/paste, color, resize]; and 3) I prefer using sudo in a GUI terminal instead of gksudo, so that I don't have to input my password every single time I open a system configuration file for editing - which is often.
I use many GUI tools this way, and none of them have the problems Geany has. I love Geany - both for system configuration file editing as well as personal file editing, but have had to quit using it because this bug prevents productivity way too often.
It is a bug because a very simple and common use case is prohibited for no good reason, shouldn't be prohibted, and no other similar tools have the same prohibition.
A fix should be simple, in theory. Either:
Sure, the second one - without additional smarts - might not catch all distributions and/or custom installs, but would cover 99%+ of the user base. And for that tiny percentage that it might not cover, their situation wouldn't be any worse that it is now.
The text was updated successfully, but these errors were encountered: