| View previous topic :: View next topic |
| Author |
Message |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
 Posted: Tue Dec 10, 2013 11:37 pm Post subject: |
 |
|
Nice, Jonathon...thanks
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
 |
roki942
Apprentice
Joined: 18 Apr 2005
Posts: 285
Location: Seattle
|
| Posted: Wed Dec 11, 2013 4:40 am Post subject: |
|
|
Thank you jonathan183  |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Wed Dec 18, 2013 6:05 am Post subject: |
|
|
| broken_chaos wrote: | | If someone ever has to use dbus-send to interact with a piece of software, the software's author has failed miserably. |
The reasons for IPC use aren't always obvious. E.g. Yubikey to issue a lock on Gnome screen saver using dbus-send. Seemed perfectly valid to me.
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
| Back to top |
|
|
Hypnos
Advocate
Joined: 18 Jul 2002
Posts: 2889
Location: Omnipresent
|
| Posted: Wed Dec 18, 2013 6:17 am Post subject: |
|
|
IPCs have been around forever, the simplest being named pipes. The problem is that dbus doesn't add much value, and with some utilities in the GNOME ecosystem the only way to interact with them from the command line is by issuing dbus messages.
_________________
Personal overlay | Simple backup scheme |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Wed Dec 18, 2013 9:33 am Post subject: |
|
|
| Hypnos wrote: | | IPCs have been around forever, the simplest being named pipes. |
I believe you mean unnamed (anonymous) for those designations. I've dealt with process threads with shared memory and semaphore use in early 90s on Sun workstations, pseudo IPC on Psion 3a, etc. Streamed pipes are obviously simpler. If I was trying to produce a GUI front end to a simple command line oriented back end process that I didn't care about having outside (of process) uniformity to anything else, I would be most likely forced to go this route.
| Quote: | | The problem is that dbus doesn't add much value |
Care to elaborate? If I was a developer of a Gnome/KDE GUI event driven app expecting to handle signal and messaging events or just to have public method call available, I'd probably use it too, unless I wanted to spend even more effort to re-invent another wheel (and probably ridiculed in the process). Why not? What would you do? It's there for that purpose. Mind you, I've also been forced to deal with CORBA years ago and I don't miss it.
I would imagine it's somewhat of an implementation of M$ WFC. That doesn't necessarily make it bad, but perhaps overkill (introspection/XML which is probably used more for RPC). I am not familiar with its details other than I thought the underlying purpose was a cross platform standard API to use for message handling on a more 'object' level with origins from KDE.
Since there are a ton of various IPC related technologies out there for at least 40 years, I've never seen them as a one size fits all.
| Quote: | | and with some utilities in the GNOME ecosystem the only way to interact with them from the command line is by issuing dbus messages. |
I'm missing your point. If that's the considered 'standardized' interface on the developed environment they listen to, why is it an issue for method calling? If I want to know about functionality from a USR1 signal being issued to dd, I still have to read and absorb such from the documentation, right?
My main concern about dbus is only if it's being enveloped, like udev/logind, into being a systemd full on cluster----. That causes me a great deal of grief when many apps that I like to use for many years, such as GIMP, may eventually become tied to the asinine enter the Matrix route.
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Wed Dec 18, 2013 10:36 am Post subject: |
|
|
| Navar wrote: | | My main concern about dbus is only if it's being enveloped, like udev/logind, into being a systemd full on cluster----. That causes me a great deal of grief when many apps that I like to use for many years, such as GIMP, may eventually become tied to the asinine enter the Matrix route. |
I've been expecting dbus to go the route of being integrated, they're heading there with the gtk+-3 beast also.
I look at systemd as an attempt to make a windows like fubar on linux,
which means they need to wrap and control everything, all for the best experience, of course. 
Dbus makes sense for some things, especially in a closed desktop environment.
It makes less sense on things like servers, or non-desktop environments, because it's overkill,
and where there are other things that can be used more easily, like old fashioned IPC.
Note: I don't run *kit, dbus, pam, systemd and udev is masked at 171.
But I don't need these things on my hybrid server/single user desktop.
Everyone elses MMV.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
| Posted: Wed Dec 18, 2013 1:50 pm Post subject: |
|
|
The Gentoo forums are supposed to be the best place a newbie finds the information he needs to implement his choice.
Needed information hiding off in the _Feedback_ forum is weird.
In this moment the whole of Gentoo forums is in such mess:
- I constantly answer howto unmerge systemd in threads titled "Howto merge systemd"
- threads having "systemd" in their title suppose ways without kit
- Gnome-3.8 threads are mostly started, because preconditions were ignored
- sticky threads are out of date
- all of the above is mixed in all forums
- while regular Gentoo-stable updates try to fundamentally change the system
Gentoo forums are the worst to get help as of now!
Would someone other than me dare to start a better titled thread about this issue? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Wed Dec 18, 2013 2:01 pm Post subject: |
|
|
Navar had a suggestion in the "Stickies - old" thread started in this subforum
about adding a sticky systemd everything thread.
Perhaps a couple of sticky threads, one about going to systemd, one about removing/avoiding systemd.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Wed Dec 18, 2013 2:34 pm Post subject: |
|
|
| ulenrich wrote: | | The Gentoo forums are supposed to be the best place a newbie finds the information he needs to implement his choice. |
When you say "are supposed to", what do you base yourself on? What does "best" mean, where do you lie the focus? Fastest? Most thorough? Categorized? Searchable? ...?
The Gentoo Forums advert themselves in the top left corner as "discussion forums"; looking for a place to find information, I rather see the Gentoo Wiki report itself with "find the information you are looking for". I'd suggest people document procedures there, and that we link to them from the forums; clearly written documentation should be more effective in helping the user. That would be more prefereable than to try to rehash something we have written a lot of times where leaving out crucial words, notes, warnings or important statements could make up the difference. Helping users further where the documentation stops is where our support and/or discussion is useful; because while the Gentoo Wiki can be a good canonical resource for general support, it falls short when it comes to details of different choices and vetting between them.
| ulenrich wrote: | | Needed information hiding off in the _Feedback_ forum is weird. |
It definitely is.
| ulenrich wrote: | In this moment the whole of Gentoo forums is in such mess:
- I constantly answer howto unmerge systemd in threads titled "Howto merge systemd" |
This is a single occasion by a foreign speaker; while it is confusing, it happened only one time as far as I am aware of.
| ulenrich wrote: | | - threads having "systemd" in their title suppose ways without kit |
As it is supposed to be, where do you see mess with this one?
| ulenrich wrote: | | - Gnome-3.8 threads are mostly started, because preconditions were ignored |
People appear to prefer direct answers to the specific questions they have than to read tons of material that is provided to them that clearly documents what they need to do; sometimes (in general, on the internet) you will remark that certain questions can yield extremely long answers and further questions to clarify the question asked, because the user hasn't read up on the subject at all. http://slash7.com/2006/12/22/vampires/
| ulenrich wrote: | | - sticky threads are out of date |
Three possible improvements: A page that gives an overview of all the sticky threads; this allows people to guard the list, to indicate what is still relevant and what is not. The community can also put the report functionality to good use to pinpoint which sticky threads are out of date and which threads should become sticky.
| ulenrich wrote: | | - all of the above is mixed in all forums |
This is a broad generalizing statement of which I doubt how true it is; that stick threads are out of date, maybe.
| ulenrich wrote: | | - while regular Gentoo-stable updates try to fundamentally change the system |
What regular fundamental change do you mean?
| ulenrich wrote: | | Gentoo forums are the worst to get help as of now! |
Q&A sites are more efficient to provide support than forums; the former focus on getting support questions answered (keeping discussion to a minimum), whereas the latter focus on discussion (distracting from support).
| ulenrich wrote: | | Would someone other than me dare to start a better titled thread about this issue? |
Yet another thread? What you really need is Q&A site; the Stack Exchange sites are exemplar in this, Gentoo questions are welcome on some of its sub sites (Unix&Linux as well as Super User) but I think creating our own sub domain (support.gentoo.org / help.gentoo.org / qa.gentoo.org / ...) will go a longer way. That being said; the forums still do a good job at it, but from a Quality Assurance perspective improvements would be nice. |
|
| Back to top |
|
|
broken_chaos
Guru
Joined: 18 Jan 2006
Posts: 370
Location: Ontario, Canada
|
| Posted: Wed Dec 18, 2013 10:46 pm Post subject: |
|
|
| Hypnos wrote: | | the only way to interact with them from the command line is by issuing dbus messages |
This is the sort of thing I was referring to when I said "failed miserably". dbus-send is not an intuitive tool, and it is not something that should have to be directly used for anything other than debugging. You can make the case that dbus-send from a shell script is little different than using libdbus/etc. from a different language, but this isn't really what I'm referring to.
A good example of what I'm referring to is BlueZ. It's a poorly-documented mess (which is partly a separate issue), and the only way to interface with it, in way too many cases, is via dbus-send directly. Something as basic as the Bluetooth stack should have a set of robust command-line utilities that have relatively straightforward access to pretty well every feature imaginable, but the recent versions have not had anything resembling this.
Perhaps the biggest flaw, though, is that requiring the use of dbus-send stuffs a user interface behind an API. Instead of being able to run foo --help to get a basic overview of how to interact with foo, you need to go look up foo's dbus API, and I'd expect that a lot of projects that do this don't exactly ship that documentation in an easy-to-read man page, either. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3266
Location: Canada
|
| Posted: Thu Dec 19, 2013 1:30 pm Post subject: |
|
|
| broken_chaos wrote: |
A good example of what I'm referring to is BlueZ. It's a poorly-documented mess (which is partly a separate issue), and the only way to interface with it, in way too many cases, is via dbus-send directly. Something as basic as the Bluetooth stack should have a set of robust command-line utilities that have relatively straightforward access to pretty well every feature imaginable, but the recent versions have not had anything resembling this.
|
It is a very good example !. What is obvious, is that with dbus design and place it occupies, there somehow no nagging pressure to build tools around it. Which shows how design decision eventually shapes the user experience. |
|
| Back to top |
|
|
Hypnos
Advocate
Joined: 18 Jul 2002
Posts: 2889
Location: Omnipresent
|
| Posted: Fri Dec 20, 2013 4:45 am Post subject: |
|
|
navar,
I finally have time to reply to your thoughtful post.
Your are right of course that anonymous pipes are a form of IPC. But I think named pipes are a closer analogue to D-Bus because they allow discovery of a process interface by searching the filesystem. With anonymous pipes the caller needs to own both the read and write processes. And Unix domain sockets are closer still because they are two-way and allow datagram communications.
The reason I say that D-Bus doesn't add value is because the only thing it does that Unix domain sockets does not is provide a standard method calling with a standard set of types. However, in an effort to be generic, the D-Bus data types are hardly more rich than the standard C data types. By contrast, with IPC in a higher-level toolkit (e.g., OPENSTEP/GNUstep) one can use the same messaging protocol and pass the same objects as in local code. And, because the D-Bus data types are standardized, you can't send high-bandwidth generic byte streams -- you have to chop up the data and pass it as arrays.
It is precisely because one size does not fit all that D-Bus is problematic. There are a diversity of IPC technologies that can do the job better in different use cases. As far as I can tell, the only reason for D-Bus to exist is to that so the different communities under the freedesktop.org umbrella can have their software talk to each other in some half-ass way.
_________________
Personal overlay | Simple backup scheme |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Sun Dec 22, 2013 12:28 am Post subject: |
|
|
Please pardon me for asking these questions, if the answers are obvious...
I've sort-of followed this thread since it started, and not seen too much light for all of the heat.
So I'll ask?
So far I've accepted consolekit, policykit, and dbus, anticipating that they're "necessary" for the contemporary desktop, even if I'm not running GNOME or KDE. But in all of the argument about systemd, which I'm determined not to accept, at least not for another year, I'm now questioning those others. So tonight I tried : "USE="-dbus -policykit -consolekit -gdu" emerge -ptuvDN world" just for jollies. I get:
| Code: | # USE="-dbus -policykit -consolekit -gdu" emerge -ptuvDN world
These are the packages that would be merged, in reverse order:
Calculating dependencies... done!
[nomerge ] xfce-extra/xfce4-mixer-4.10.0 USE="alsa -debug -oss"
[ebuild R ] dev-libs/libunique-1.1.6-r1:1 USE="introspection -dbus* -debug -doc {-test}" 0 kB
[nomerge ] x11-themes/gdm-themes-20070811-r1
[ebuild R ] gnome-base/gdm-2.20.11-r1 USE="branding pam tcpd -accessibility -afs -consolekit* -dmx -gnome-keyring -ipv6 -remote (-selinux) -xinerama" 0 kB
[nomerge ] xfce-base/xfce4-meta-4.10 USE="svg -minimal"
[ebuild R ] xfce-base/xfce4-session-4.10.0-r1 USE="udev xscreensaver -consolekit* -debug -gnome-keyring -policykit*" 0 kB
[nomerge ] app-text/calibre-1.2 USE="udisks"
[ebuild R ] dev-python/PyQt4-4.10.2 USE="X opengl svg webkit -dbus* -debug -declarative -doc -examples -help -kde -multimedia -phonon -script -scripttools -sql -xmlpatterns" PYTHON_TARGETS="python2_7 python3_3 -python2_6 -python3_2" 0 kB
[nomerge ] games-engines/scummvm-1.5.0 USE="aac alsa flac fluidsynth mp3 opengl truetype vorbis -debug"
[ebuild R ] media-sound/fluidsynth-1.1.6 USE="alsa readline sndfile -dbus* -debug -examples -jack -ladspa -lash -portaudio -pulseaudio" 0 kB
[ebuild R ] www-client/firefox-24.2.0 USE="alsa jit libnotify minimal startup-notification -bindist -custom-cflags -custom-optimization -dbus* -debug -gstreamer (-pgo) -pulseaudio (-selinux) -system-cairo -system-icu -system-jpeg -system-sqlite -wifi" LINGUAS="-af -ak -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -csb -cy -da -de -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -fr -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km -kn -ko -ku -lg -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -nso -or -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -ta_LK -te -th -tr -uk -vi -zh_CN -zh_TW -zu" 7 kB
[ebuild R ] app-text/evince-2.32.0-r4 USE="introspection postscript tiff -dbus* -debug -djvu -dvi -gnome -gnome-keyring -nautilus -t1lib" 0 kB
[ebuild R ] x11-terms/xfce4-terminal-0.4.8 USE="-dbus* -debug" 0 kB
[ebuild R ] sys-block/gparted-0.16.2 USE="btrfs dmraid fat xfs -f2fs -hfs -jfs -kde -mdadm -ntfs -policykit* -reiser4 -reiserfs" 0 kB
[ebuild R ] net-dns/dnsmasq-2.66 USE="nls -auth-dns -conntrack -dbus* -dhcp -dhcp-tools -idn -ipv6 -lua -script (-selinux) -tftp" LINGUAS="es -de -fi -fr -id -it -no -pl -pt_BR -ro" 0 kB
[ebuild R ] net-im/pidgin-2.10.7-r5 USE="gnutls gstreamer gtk meanwhile ncurses nls perl python spell tcl tk xscreensaver (-aqua) -dbus* -debug -doc -eds -gadu -groupwise -idn -mxit -networkmanager -prediction -sasl -silc -zephyr -zeroconf" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" 0 kB
[ebuild R ] gnome-base/gnome-applets-2.32.1.1-r2 USE="cpufreq -gstreamer -ipv6 -networkmanager -policykit*" 0 kB
[ebuild R ] x11-apps/xdm-1.1.11-r3 USE="pam -consolekit* -ipv6 -xdm-auth" 0 kB
[ebuild R ] mail-client/thunderbird-24.2.0 USE="alsa crypt jit libnotify lightning minimal startup-notification -bindist -custom-cflags -custom-optimization -dbus* -debug -gstreamer -ldap -mozdom -pulseaudio (-selinux) -system-cairo -system-icu -system-jpeg -system-sqlite -wifi" LINGUAS="-ar -ast -be -bg -bn_BD -br -ca -cs -da -de -el -en_GB -es_AR -es_ES -et -eu -fi -fr -fy_NL -ga_IE -gd -gl -he -hr -hu -hy_AM -id -is -it -ja -ko -lt -nb_NO -nl -nn_NO -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -sq -sr -sv_SE -ta_LK -tr -uk -vi -zh_CN -zh_TW" 0 kB
[nomerge ] gnome-base/gnome-applets-2.32.1.1-r2 USE="cpufreq -gstreamer -ipv6 -networkmanager -policykit*"
[ebuild R ] gnome-base/gnome-settings-daemon-2.32.1-r2 USE="libnotify -debug -policykit* -pulseaudio -smartcard" 0 kB
[nomerge ] net-print/foomatic-db-4.0.20120831
[nomerge ] net-print/foomatic-db-engine-4.0.9
[ebuild R ] net-print/foomatic-filters-4.0.17-r1 USE="cups -dbus*" 0 kB
[ebuild R ] app-text/ghostscript-gpl-9.05-r1 USE="X cups gtk -bindist -dbus* -djvu -idn -jpeg2k -static-libs" LINGUAS="-ja -ko -zh_CN -zh_TW" 0 kB
[nomerge ] gnome-base/gnome-applets-2.32.1.1-r2 USE="cpufreq -gstreamer -ipv6 -networkmanager -policykit*"
[nomerge ] dev-python/gnome-applets-python-2.32.0 USE="-examples"
[nomerge ] gnome-base/libgnomeui-2.24.5 USE="-doc {-test}"
[nomerge ] gnome-base/gnome-keyring-2.32.1-r1 USE="pam -debug {-test}"
[ebuild R ] gnome-base/gconf-2.32.4-r1:2 USE="gtk introspection -debug -ldap -policykit*" 0 kB
[ebuild R ] net-print/cups-1.6.4 USE="X acl filters gnutls pam python ssl threads -dbus* -debug -java -kerberos -lprng-compat (-selinux) -static-libs -usb -xinetd -zeroconf" LINGUAS="es -ca -fr -ja -ru" PYTHON_SINGLE_TARGET="python2_7 -python2_6" PYTHON_TARGETS="python2_7 -python2_6" 0 kB
[nomerge ] sys-apps/openrc-0.12.4 USE="ncurses netifrc pam unicode -debug -newnet (-prefix) (-selinux) -static-libs -tools"
[ebuild R ] sys-auth/pambase-20120417-r3 USE="cracklib sha512 -consolekit* -debug -gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -passwdqc (-selinux) -systemd" 0 kB
Total: 20 packages (20 reinstalls), Size of downloads: 7 kB |
So it doesn't actually look like that bad a thing to do, at first blush. Many packages are getting rebuilt, but none are reporting this as an impossible change.
So here are the questions:
1 - What am I losing by doing this?
2 - How do I work around that?
I know consolekit grants additional privileges to the console user, but beyond making sure users are in the correct groups, what else is needed, and do I really want to work around all of those lacks, or is "su" or "sudu" really better, anyway?
ps - Just for jollies I'm trying it again, adding "-introspection" to my USE flags.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Hypnos
Advocate
Joined: 18 Jul 2002
Posts: 2889
Location: Omnipresent
|
| Posted: Sun Dec 22, 2013 1:50 am Post subject: |
|
|
I'm not familiar with all the software installed on your machine, so I can't tell you exactly what you'll be losing.
In my case, by disabling consolekit I lost the ability to suspend/hibernate/shutdown/reboot from the XFCE desktop menu. For suspend and hibernate I just created wrapper scripts around sudo and connected those to keyboard shortcuts.
I lost nothing additional by disabling policykit, as consolekit was the only package on my system depending on policykit.
I still have dbus because it is an unconditional dependency for wicd (via dbus-python), pm-utils and xfce4-notifyd, for which I have not yet found suitable replacements. Though, I guess I could try disabling the dbus USE flag and see what happens with other packages.
I don't know what I'm missing by not having gdu enabled.
HTH
_________________
Personal overlay | Simple backup scheme |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Sun Dec 22, 2013 2:18 am Post subject: |
|
|
| Hypnos wrote: |
I still have dbus because it is an unconditional dependency for wicd (via dbus-python), pm-utils and xfce4-notifyd, for which I have not yet found suitable replacements. Though, I guess I could try disabling the dbus USE flag and see what happens with other packages.
|
On one machine I have pm-utils, and on another I have hibernate-script - both basically for the suspend function. Right now I have dbus, consolekit, and policykit, I'm just looking at getting rid of them.
I also use gdm, and slim has been recommended. However I looked at the slim page, and it won't suspend/reboot/poweroff without either "special accounts" and the root password, or logging on and using sudo. Once upon a time I used xdm, and had some tk code to add buttons to the login screen. Sadly, I lost that code after migrating to gdm.
As for xfce4-notifyd, sometimes I find notification popups annoying, and it might be nice to get rid of them.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Dec 22, 2013 10:26 am Post subject: |
|
|
| depontius wrote: | | consolekit, policykit, and dbus, anticipating that they're "necessary" [...] systemd, which I'm determined not to accept |
Since technical and political arguments are often mixed up here, I think one should separate more clearly.
- polkit is a real threat to the security of your system. Better avoid it at any price.
- systemd, on the other hand, does currently not force you to many things except for wasting resources for its daemons/journal/... (and is very hard to use if you need something not explicitly supported, but that's not an issue for "typical" desktop users). This might change in some future, but except for political considerations there is currently not a severe technical argument to avoid it.
- dbus is not bad per se - neither political nor technical. Only using it to raise permissions is dangerous, but this can hardly happen without polkit. I am not yet decided whether the systemd daemons fall into the same dangerous category with dbus (since they are all "controlled" over dbus). Maybe somebody has more information how easy it is to fake a wrong identity to dbus (using races or whatever).
- For the same reason, I am also not yet decided about consolekit/systemd-logind: It has the potential to do severe damage, but it is not such a complex thing like polkit and thus perhaps the "risk" is reasonable (not larger than to get an exploit in a kernel in some random place).
- Combining pam with polkit is probably the most severe security disaster one can do since the combinations of possible attacks is almost impossible to overlook
|
|
| Back to top |
|
|
Hypnos
Advocate
Joined: 18 Jul 2002
Posts: 2889
Location: Omnipresent
|
| Posted: Sun Dec 22, 2013 12:14 pm Post subject: |
|
|
| mv wrote: | | dbus is not bad per se - neither political nor technical. Only using it to raise permissions is dangerous, but this can hardly happen without polkit. I am not yet decided whether the systemd daemons fall into the same dangerous category with dbus (since they are all "controlled" over dbus). Maybe somebody has more information how easy it is to fake a wrong identity to dbus (using races or whatever). |
D-Bus uses a magic cookie authentication system so the protocol itself is no less secure than X11; I don't know about the implementation (there has been at least one bug). I agree the main security problem is that polkit makes it so easy to puncture the superuser/user barrier.
However, I would argue that D-Bus still presents a technical problem because of its half-ass design -- see my reply to navar above.
_________________
Personal overlay | Simple backup scheme |
|
| Back to top |
|
|
schorsch_76
Guru
Joined: 19 Jun 2012
Posts: 450
|
| Posted: Sun Dec 22, 2013 2:46 pm Post subject: |
|
|
| Hypnos wrote: | I'm not familiar with all the software installed on your machine, so I can't tell you exactly what you'll be losing.
In my case, by disabling consolekit I lost the ability to suspend/hibernate/shutdown/reboot from the XFCE desktop menu. For suspend and hibernate I just created wrapper scripts around sudo and connected those to keyboard shortcuts.
I lost nothing additional by disabling policykit, as consolekit was the only package on my system depending on policykit.
I still have dbus because it is an unconditional dependency for wicd (via dbus-python), pm-utils and xfce4-notifyd, for which I have not yet found suitable replacements. Though, I guess I could try disabling the dbus USE flag and see what happens with other packages.
I don't know what I'm missing by not having gdu enabled.
HTH |
For shutdown, hibernate reboot and stuff, there is sudo available. You can grant access to specific actions by groups/names etc. There should be a use set for these actions, that they use sudo instead of dbus....
without a dbus use flag, if i start vlc and only want one instance and double click the next movie, i get two instances of vlc. This is obiously handled by dbus, but there are other forms of IPC, which could be used for this.
This is all what i know from my expierence, what you loose, if you disable dbus. consolekit/polkit are already mentioned.
What concerns me, is that the "lightwight" pcmanfm requires polkit/consolekit. They are masked on my machine .... there is no useflag for that. That is only a filemanager, nothing else. Why in gods sake does it need dbus/polkit/consolekit? All i want from it is to move/rename/delete files and start applications by doubleclicking. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Sun Dec 22, 2013 3:09 pm Post subject: |
|
|
| schorsch_76 wrote: | | What concerns me, is that the "lightwight" pcmanfm requires polkit/consolekit. They are masked on my machine .... there is no useflag for that. That is only a filemanager, nothing else. Why in gods sake does it need dbus/polkit/consolekit? All i want from it is to move/rename/delete files and start applications by doubleclicking. |
It doesn't require consolekit, at least with the use flags I have set.
It does want to pull in gvfs[udev], well libfm actually, but I modified the ebuild to make it stop doing that.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Sun Dec 22, 2013 5:04 pm Post subject: |
|
|
| mv wrote: |
Since technical and political arguments are often mixed up here, I think one should separate more clearly.
- polkit is a real threat to the security of your system. Better avoid it at any price.
- systemd, on the other hand, does currently not force you to many things except for wasting resources for its daemons/journal/... (and is very hard to use if you need something not explicitly supported, but that's not an issue for "typical" desktop users). This might change in some future, but except for political considerations there is currently not a severe technical argument to avoid it.
- dbus is not bad per se - neither political nor technical. Only using it to raise permissions is dangerous, but this can hardly happen without polkit. I am not yet decided whether the systemd daemons fall into the same dangerous category with dbus (since they are all "controlled" over dbus). Maybe somebody has more information how easy it is to fake a wrong identity to dbus (using races or whatever).
- For the same reason, I am also not yet decided about consolekit/systemd-logind: It has the potential to do severe damage, but it is not such a complex thing like polkit and thus perhaps the "risk" is reasonable (not larger than to get an exploit in a kernel in some random place).
- Combining pam with polkit is probably the most severe security disaster one can do since the combinations of possible attacks is almost impossible to overlook
|
Is your security beef with polkit the fact that it exists at all, the quality of the software, or the quality of the policies they've written?
I'm of mixed feelings, because the alternative is either "su -" or some sort of sudo wrapper. By itself, "su -" grants even more than polkit or sudo. As for sudo, I'm not really sure how different sudo and polkit are, when you get right down to it. Both are basically a policy mechanism.
I have a real problem with systemd, perhaps because my beard does happen to be grey, I rather strongly approve of "The Unix Way," and feel that in a world where no software is perfect, a good philosophy will help you better survive bad software than good software will help you survive a bad philosophy. Really the whole security way of "defense in depth" is an illustration of this.
As a furthering of that, I strongly suspect that systemd and dbus have a whole new batch of security vulnerabilities that simply haven't been probed yet. I haven't once heard the phrase "privilege separation" used in discussions, which so burned openssh many years ago, and was a lesson hard-learned. If nothing else, freedesktop.org seems to have taken a stance that that old Unix stuff is what's holding Linux back on the desktop, and deliberately ignored, if not avoided it.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Hypnos
Advocate
Joined: 18 Jul 2002
Posts: 2889
Location: Omnipresent
|
| Posted: Sun Dec 22, 2013 6:44 pm Post subject: |
|
|
| depontius wrote: | [...] As for sudo, I'm not really sure how different sudo and polkit are, when you get right down to it. Both are basically a policy mechanism.
I have a real problem with systemd, perhaps because my beard does happen to be grey, I rather strongly approve of "The Unix Way," and feel that in a world where no software is perfect, a good philosophy will help you better survive bad software than good software will help you survive a bad philosophy. Really the whole security way of "defense in depth" is an illustration of this. |
sudo is the "Unix Way" method for creating policy exceptions. It is a simple-yet-powerful tool that allows nothing by default.
| Quote: | | As a furthering of that, I strongly suspect that systemd and dbus have a whole new batch of security vulnerabilities that simply haven't been probed yet. I haven't once heard the phrase "privilege separation" used in discussions, which so burned openssh many years ago, and was a lesson hard-learned. If nothing else, freedesktop.org seems to have taken a stance that that old Unix stuff is what's holding Linux back on the desktop, and deliberately ignored, if not avoided it. |
Yup.
_________________
Personal overlay | Simple backup scheme |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Dec 22, 2013 7:27 pm Post subject: |
|
|
| depontius wrote: | | Is your security beef with polkit the fact that it exists at all, the quality of the software, or the quality of the policies they've written? |
The main problem is that it exists at all; it is so complex that it is not possible to expect a secure implementation. There were already many races found and fixed in connection with polkit (if you like, I can post links to some dozens or so, already), but it is clear that this is a bottomless pit. Broken design decisions like using javascript show that also the quality of the software itself cannot be trusted (I just recently learnt that the reason for javascript instead of a saner language like lua was just the maintainer is more familiar with it; such an argument alone - dumping a recognized better solution due to own incompetence - is a reason to not give any cent of trust into such a software). I have not attempted to follow the policies in detail, but their mere number indicates that one cannot trust them. This was already the main problem with pam, but combined with polkit the complexity for a system which is meant to execute security relevant tasks is out of discussion. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Forums Feedback
