Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Am I being forced to use systemd now?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6 ... 18, 19, 20  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3567
Location: Dallas area

PostPosted: Tue Jun 10, 2014 7:01 pm    Post subject: Reply with quote

The *kit's only make sense in a multi-user server environment, which is in a minority.
By far most systems are single user, or perhaps a small multi-user systems (family, etc) where everyone is trusted.

I think the whole *kit philosophy is a solution in search of a problem.

Just my opinion.
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 7.3.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6935
Location: almost Mile High in the USA

PostPosted: Tue Jun 10, 2014 8:17 pm    Post subject: Reply with quote

Educational institutions with computer labs and even office environments (but they tend to use Windows, so not really an issue) - there are a lot of machines used this way where users may not trust each other. So this does solve one real problem...
Back to top
View user's profile Send private message
SDNick484
Apprentice
Apprentice


Joined: 05 Dec 2005
Posts: 212

PostPosted: Wed Jun 11, 2014 2:41 am    Post subject: Reply with quote

pygoscelis wrote:
Trying to emerge upower-pm-utils but this wants to pull in systemd.

Code:
emerge -p --oneshot --noreplace 'sys-power/upower-pm-utils'

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] sys-apps/systemd-212-r5  USE="acl filecaps firmware-loader gudev introspection kmod pam (policykit) seccomp -audit -cryptsetup -doc -gcrypt -http (-kdbus) -lzma -python -qrcode (-selinux) (-ssl) {-test} -vanilla -xattr" ABI_X86="(64) (-32) (-x32)" PYTHON_SINGLE_TARGET="python2_7 -python3_2 -python3_3" PYTHON_TARGETS="python2_7 python3_3 -python3_2"
[ebuild  N     ] sys-apps/gentoo-systemd-integration-4
[ebuild  N     ] virtual/libgudev-208  USE="introspection -static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] sys-power/upower-pm-utils-0.9.23  USE="introspection -doc -ios"
[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/udev-208)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (sys-fs/udev-208::gentoo, installed) pulled in by
    >=sys-fs/udev-208[abi_x86_64(-),gudev,introspection,kmod] required by (virtual/udev-208-r1::gentoo, installed)

  (sys-apps/systemd-212-r5::gentoo, ebuild scheduled for merge) pulled in by
    >=sys-apps/systemd-208:0/2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,gudev,introspection?,static-libs(-)?] (>=sys-apps/systemd-208:0/2[abi_x86_64(-),gudev,introspection]) required by (virtual/libgudev-208::gentoo, ebuild scheduled for merge)
    >=sys-apps/systemd-207 required by (sys-apps/gentoo-systemd-integration-4::gentoo, ebuild scheduled for merge)


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked


Why?


I ran into this as well; I think the cause was being on an older version of udev (I was on 208, and you appear to be as well) I had to:
1. emerge -C upower
2. emerge upower-pm-utils udev
Back to top
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Wed Jun 11, 2014 5:00 am    Post subject: Reply with quote

eccerr0r wrote:
Educational institutions with computer labs and even office environments (but they tend to use Windows, so not really an issue) - there are a lot of machines used this way where users may not trust each other. So this does solve one real problem...


But this can be managed by group permissions too. That user_A can not look into the home directory of user_B. What is the needed feature which is missing from standard group/user permissions?
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6935
Location: almost Mile High in the USA

PostPosted: Thu Jun 12, 2014 7:07 pm    Post subject: Reply with quote

schorsch_76 wrote:
But this can be managed by group permissions too. That user_A can not look into the home directory of user_B. What is the needed feature which is missing from standard group/user permissions?


Not sure how much sysadmining background everyone has with the standard user/group permissions, but let me tell you, though it works, it is extremely cumbersome (we're talking about power policy here not data privacy). Also, when someone is allowed to login remotely as well as be on console, you don't want them to DoS the machine to other remote logins. Granted sure, that person can go and run to the console and piss people off during after hours where admins may not be available to turn it back on, but let's not get into that. (And yes if you're at console you should always be able to shutdown/reboot/hibernate/suspend the machine even if you don't own it... It's the "all bets are off" sysadmining rule when one has console access.)

I can't say that systemd is a good thing, but having a library and a console policy is good just to make sure hardware routines stay separate from UI routines, so it won't be tough to port to other platforms where perhaps there is no remote login.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Jun 12, 2014 9:43 pm    Post subject: Reply with quote

schorsch_76 wrote:
steveL wrote:
If other apps = DE, is there any other app you think should have the ability to do that?

If so, why would a simple command be inappropriate?

Good question. I cant answer it, because i wasn't involved at the design. As far as i understand it, they wanted to put polkit between the command and the execution of the actual hibernate command (from every point where it could be called from the system). As far as i understand polkit, it should provide a better right management than standard groups (but dont ask me if it is better or not). I actually dont know any permission thing which could not be managed by groups or ACL's from the kernel. Maybe some other person has more insight into polkit.

From my point of view, they wanted to control the whole system through dbus and control user sessions with consolekit and permissions with polkit.

Yes, they want everything to go via their software. I'm still not seeing the benefit to the admin.
depontius wrote:

I believe the goal here is to confer rights on the console user, not on any specific user. So individual users have no console rights, the DE knows who is at the console, and consolekit/polkit do the privileged stuff on their behalf. At that point I might have to agree that using dbus as the communications medium, but maybe not. At first blush command-line options seem more subject to abuse than dbus messages. But then again, that belief is itself security-by-obscurity, since I'm sure some sort of malware could come out that issues dbus messages to do its dirty work. If the people listening to dbus to do stuff like this think that they're safe, then they are very likely not.

Agreed; dbus is a security nightmare, afaic. Regardless, it's still only the DE that we're talking about, and frankly I'd rather it just called a hibernate or suspend command (that handled the underlying system and locking). It's already a privileged process, and I don't see the value in opening this capability to the desktop bus for other apps. Only lots of unneeded security issues.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Jun 12, 2014 9:50 pm    Post subject: Reply with quote

eccerr0r wrote:
Educational institutions with computer labs and even office environments (but they tend to use Windows, so not really an issue) - there are a lot of machines used this way where users may not trust each other. So this does solve one real problem...

Yes, this is the pretext that was given for consolekit and it was thoroughly debunked in a conference presentation that's on YouTube somewhere. It was given by a net admin at a German Uni who'd spent years trying to make the combination work, and was hijacked by Poettering, who made lots of noise but remained very unconvincing.

It doesn't work: it just enables people to pretend that "fast-user switching" is here, like that's the really important thing. Meantime polkit leaves devices open to the last user, last I checked. There certainly didn't seem to be any plan to fix the problem, and that attitude from a library that's supposed to handle security not only sucks, it lulls people into a false sense of security, since they think it's taken care of by the RH "experts" who tell them everything's far too complex for their little heads to handle.

Give me pam any day. (Yes I know polkit can work with it; thing is we can work better without polkit.)
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6935
Location: almost Mile High in the USA

PostPosted: Thu Jun 12, 2014 11:32 pm    Post subject: Reply with quote

There are tons of way to skin a cat, but it would be nice to have a library and IPC method (so all software has a common method) to handle these poweroff/suspend/hibernate commands. All of these require root privledges to do, of course, but regular users shouldn't be able to do them - unless they're logged in onto the console.

Sure you can always roll your own, but centralizing this all into common routines helps out with the security auditing. Yes it's yet another piece of code, but hopefully one audit will help all desktop environments deal with root for shutdown/suspend/hibernate.

I suspect the main reason it got absorbed into systemd is because shutdown is very well tied with systemd, and it indeed is a power-related routine. It's too bad suspend to RAM/hibernate got taken along for the "ride to doom".
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Fri Jun 13, 2014 5:43 am    Post subject: Reply with quote

eccerr0r wrote:
schorsch_76 wrote:
But this can be managed by group permissions too. That user_A can not look into the home directory of user_B. What is the needed feature which is missing from standard group/user permissions?


Not sure how much sysadmining background everyone has with the standard user/group permissions, but let me tell you, though it works, it is extremely cumbersome (we're talking about power policy here not data privacy). Also, when someone is allowed to login remotely as well as be on console, you don't want them to DoS the machine to other remote logins. Granted sure, that person can go and run to the console and piss people off during after hours where admins may not be available to turn it back on, but let's not get into that. (And yes if you're at console you should always be able to shutdown/reboot/hibernate/suspend the machine even if you don't own it... It's the "all bets are off" sysadmining rule when one has console access.)

I can't say that systemd is a good thing, but having a library and a console policy is good just to make sure hardware routines stay separate from UI routines, so it won't be tough to port to other platforms where perhaps there is no remote login.


console access is still protected by the user/group right management. If your group/user permissions are right, then a user with console access (be it remote or local) can not shutdown the machine. (yes, your root password should be a good one). Not ever user needs to be in the wheel group.

If your users, use your machine to DoS other machines in the network, you have done some substantial errors at recruiting people which use your machine. If the users just use up the computing power with their programs, there is a kernel thing called cgroups where you can limit their available cpu time. Yes, you can even use it without systemd.

I assume it is just easy to accept every direction redhat chooses to go.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Jun 13, 2014 8:12 am    Post subject: Reply with quote

eccerr0r wrote:
There are tons of way to skin a cat, but it would be nice to have a library and IPC method (so all software has a common method) to handle these poweroff/suspend/hibernate commands. All of these require root privledges to do, of course, but regular users shouldn't be able to do them - unless they're logged in onto the console.

I can't follow this logic at all. If you have a command you can set the privileges how you like, whether via group permissions, simply requiring root, via acl or pam, sudo etc. All the standard mechanisms. depontius said above that "the DE knows who is at the console", so why on earth should the DE not simply run the command, instead of calling out via dbus and polkit and all this other stuff?

It's been working since the late 90s for shutdown/reboot ime, so I can't see why it's suddenly necessary to make things complexified.
Quote:
Sure you can always roll your own, but centralizing this all into common routines helps out with the security auditing. Yes it's yet another piece of code, but hopefully one audit will help all desktop environments deal with root for shutdown/suspend/hibernate.

Or you know, you could just continue to use commands like we've always done, and centralise the effort there instead, with a simple cleaner implementation that is much easier to analyse since it only does one thing, and further doesn't need more than libc.

Or in the case of a script to cope with variant mechanisms for hibernate/suspend, we might use a central script that we can collaborate on to make sure it's done right (ie robust as well as functional.) That's fine since one of the things we want is the ability to run user-hooks, and sh is quick; it enables us to do the Rapid Development thing, and is transparent to the user and each other. And if we're running shell hooks anyway, we might as well, so long as we have correct locking (one reason I found the existing scripts interesting.)
Oh and of course, we write correct shell, just like we'd expect correct C or [any other language.]

By all means codify that in C if it makes a real difference. You'll have a lot less to worry about, and it'll be much easier to audit.
But don't expect that it'll buy you any real performance gain in the overall scheme of things (this is hardly a bottleneck); nor is it any more correct. You can't fix races like that.
Quote:
I suspect the main reason it got absorbed into systemd is because shutdown is very well tied with systemd, and it indeed is a power-related routine. It's too bad suspend to RAM/hibernate got taken along for the "ride to doom".

Dunno, I rather suspect the main reason things get absorbed in systemd is the "Embrace, Cripple, Extinguish" business-strategy we've seen so many times with this upstream.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6935
Location: almost Mile High in the USA

PostPosted: Fri Jun 13, 2014 2:40 pm    Post subject: Reply with quote

steveL wrote:
If you have a command you can set the privileges how you like, whether via group permissions, simply requiring root, via acl or pam, sudo etc. All the standard mechanisms. depontius said above that "the DE knows who is at the console", so why on earth should the DE not simply run the command, instead of calling out via dbus and polkit and all this other stuff?

It's been working since the late 90s for shutdown/reboot ime, so I can't see why it's suddenly necessary to make things complexified.


Agreed, a lot of this stuff can be emulated by the clever use of sudo scripts, but again the maintenance of the ACLs has always been an PITA. Again, the console user should _ALWAYS_ be able to shutdown the machine no matter what, they are at the whim of the power cord, ethernet cable, etc. anyway, at least let them have the controls to preserve the integrity of the data on the machine. The DE software should automatically allow all power-related commands to the console user without having to deal with ACLs. We can't resort to "It's their computer, let them break their own data" any more, it's not necessarily their computer.

I do not disagree this polkit, consolekit, dbus crap is all very complicated and confusing but I feel that a lot of resistance is due to NIH and "but it's always been done this way." Someday I'd like to figure out all this dbus stuff - I think it's a complicated unauditable piece of crap myself - but at the root it's just another form of IPC to pass data between kernel and DE without expensive forking.

Apparently I really think it's just the Unix diehards that believe systemd is "embrace, cripple, extinguish" as it destroys the classic, simple to understand, and working init system. However dbus IPC does give a tighter coupling between the DE and system/kernel without having them be one and the same, which is apparently how Windows works. Keep in mind too that the systemd revolution appears to be winning for some reason. RHEL isn't even the most popular distribution even amongst enterprise users, yet slowly distribution by distribution, somehow dbus/systemd is being adopted for some reason... There must be some benefits to it...

I really would like to hear why the Gentoo devs even allowed systemd in portage. It was completely their choice whether to even have Gnome3. There's absolutely no reason why Gentoo has to have Gnome3 in portage at all and thus systemd.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Jun 13, 2014 3:46 pm    Post subject: Reply with quote

eccerr0r wrote:
steveL wrote:
If you have a command you can set the privileges how you like, whether via group permissions, simply requiring root, via acl or pam, sudo etc. All the standard mechanisms. depontius said above that "the DE knows who is at the console", so why on earth should the DE not simply run the command, instead of calling out via dbus and polkit and all this other stuff?

It's been working since the late 90s for shutdown/reboot ime, so I can't see why it's suddenly necessary to make things complexified.


Agreed, a lot of this stuff can be emulated by the clever use of sudo scripts, but again the maintenance of the ACLs has always been an PITA. Again, the console user should _ALWAYS_ be able to shutdown the machine no matter what, they are at the whim of the power cord, ethernet cable, etc. anyway, at least let them have the controls to preserve the integrity of the data on the machine. The DE software should automatically allow all power-related commands to the console user without having to deal with ACLs. We can't resort to "It's their computer, let them break their own data" any more, it's not necessarily their computer.

I'd argue it's the other way round: with all this spaghetti-lasagna-fest, you can emulate the simple mechanism of running a command.

There is zero benefit to doing so, but you can. Again, nothing in what you've written explains why the DE can't just run the command. It's already privileged, in the overall scheme of things. If you prefer, s/DM/DE since they're usually coupled, but in any event communication between a DM and the DE it starts is already much less to worry about (if the DE is running as user). And no, it does not need to go via the dbus, nor should it. The DM starts the DE, perhaps in a cgroup (as schorsch pointed out cgroups were around long before systemd).
Quote:
I do not disagree this polkit, consolekit, dbus crap is all very complicated and confusing but I feel that a lot of resistance is due to NIH and "but it's always been done this way." Someday I'd like to figure out all this dbus stuff - I think it's a complicated unauditable piece of crap myself - but at the root it's just another form of IPC to pass data between kernel and DE without expensive forking.

No it's not confusing: it's just crap. We can outline the ways it's crap, and that can get confusing, but ultimately it's simply crap.

IPC does not require forking. And you certainly don't need to fork to talk to the kernel; that's what syscalls are for.

Sure some forms of IPC are only available between descendants of the same process, such as unnamed pipes. But that's what named pipes (aka FIFOs) are for, if that is the mechanism with the best semantic for the job. And others are available besides (message queues and shared memory) without any requirement for shared ancestry. Pipes are just convenient (and efficient) when you have forked, and even more so when you exec another image.
Quote:
Apparently I really think it's just the Unix diehards that believe systemd is "embrace, cripple, extinguish" as it destroys the classic, simple to understand, and working init system.

Dunno who else; I'm just basing that on projects like the hwdb and pci-ids, which you basically cannot use outside udev any more: they don't exist as separate projects, despite long histories as exactly that. And ofc udev itself, and now we have the power stuff. Thankfully we have eudev, and I'm very impressed with the review that goes into each and every commit there.

However that doesn't change that this is badly designed: more and more components are swallowed into the amorphous project; each time we're promised that things will continue to work as they always have, and each time that's shown to be false a few versions later.
Quote:
However dbus IPC does give a tighter coupling between the DE and system/kernel without having them be one and the same, which is apparently how Windows works.

The context of your statement implies that this is an argument in favour of the inturgrated approach; the content belies that. ;)
Quote:
Keep in mind too that the systemd revolution appears to be winning for some reason. RHEL isn't even the most popular distribution even amongst enterprise users, yet slowly distribution by distribution, somehow dbus/systemd is being adopted for some reason... There must be some benefits to it...

You sound like you're trying to convince yourself much more than anyone else ;)

With respect, other distros never had openrc, and other distros wrote absolutely god-awful bashish (all the bloat of bash, with all the pain of sh, usually to be blamed on TLDP ABS) that they then used as justification for why "shell is bad".

[Obligatory disclaimer] By all means use systemd if you, or anyone else wants. [/disclaimer, oft repeated, oft ignored..]

If your distro delivers crappy shellscripts, then sure there's a benefit to not using their crappy shell.
There are alternatives to both choices, but if that's the route you choose, good luck to you.

IDK how anyone can call systemd anything other than "pre-production" software, but it's not my debian install.
Quote:
I really would like to hear why the Gentoo devs even allowed systemd in portage. It was completely their choice whether to even have Gnome3. There's absolutely no reason why Gentoo has to have Gnome3 in portage at all and thus systemd.

I had, and still have, no issue with systemd being packaged in Gentoo. I am annoyed that the systemd profiles which were agreed upon as the way forward, haven't been used properly; instead we've had constant leakage into default profiles, and hand-waving about how users are supposed to be able to cope with all sorts of dependency changes, yay even if they are a home-user, and verily even if we said we'd keep it in its sandbox.

But apparently we're too stupid to configure permissions when we're working as admins.

And we're so dumb we don't pay attention to stated plans of "gently pushing" people via auto-installed dependencies, which ofc don't fly on Gentoo as they would on a bindist.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6935
Location: almost Mile High in the USA

PostPosted: Fri Jun 13, 2014 6:13 pm    Post subject: Reply with quote

Syscalls require root permissions, and you need to fork an SUID process to get those permissions, hence IPC is faster to get at privileged routines (and dbus just uses the there-since antiquity Unix sockets anyway, and they are shareable, bidirectional, and maintain UID/GID). So what do you propose as a non-fork method that safely allows any console user, regardless of DE, to do power operations and still prevent remote users who can walk up to the console or screen sessions initiated from the console from doing the same?

Honestly I really don't care one way or the other. There are benefits to both and certainly not an issue for a predominantly single-user-on-console computer. Do I think systemd/dbus is better than init? Both have their advantages, both have disadvantages. I currently run both init/openrc and systemd machines at home and am more pissed at having to change than actually using systemd. In fact it's the breakage caused by changing (rewriting custom init scripts and configurations) that's stopping me from changing all over to systemd to keep a unified environment.

And why, if systemd is so bad, is basically all major Linux distributions adopting it? Obviously if it's bad, everyone would simply not use it. But even Debian uses it now. It's the popular distribution devs that end up determining pervasiveness; if they think it's that bad, they shouldn't include it at all, option or not. Is Gentoo a fencesitter like me for the most part?

And as a end user admin it's your duty to prevent systemd from installing, not the distribution - you control what's on your computer. And yes on most of my init machines:

/etc/portage/packages.mask/general.mask wrote:
sys-apps/systemd


Goes a long way from accidental installs. And it's not the distribution packager's fault for certain applications that require any particular package, it's all upstream.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3353

PostPosted: Fri Jun 13, 2014 6:22 pm    Post subject: Reply with quote

[quote="steveL"
There is zero benefit to doing so, but you can. Again, nothing in what you've written explains why the DE can't just run the command. It's already privileged, in the overall scheme of things. If you prefer, s/DM/DE since they're usually coupled, but in any event communication between a DM and the DE it starts is already much less to worry about (if the DE is running as user). And no, it does not need to go via the dbus, nor should it. The DM starts the DE, perhaps in a cgroup (as schorsch pointed out cgroups were around long before systemd).
[/quote]

My issue here is that once we get to non-root X, neither the DM nor the DE will be running root. The DM will probably be running as nobody, though perhaps it will run as "dmuser", and the DE will be running as me. At that point neither is privileged, though the DM might look a little more special, in terms of being granted extra privilege.

I don't really see how simple groups do the job. This isn't just suspend, hibernate, shutdown, and reboot. It's also cdrom and usb access, since those are also associated with the console. As someone else, perhaps even you have said, the console user simply needs that level of basic access, or they could push the power button (for 30 sec) to do what they can't do on-screen. Even an idea like just-in-time group updates - add me to "console" just before my console session is turned over to me - doesn't really hack it. Groups are processed at login, hence the need to add me prior to handing me the session. But let's say my console session is hung - then my being able to ssh in and have console privilege is good - it will let me get out of trouble. But let's say I'm evil - I login at the console, then ssh in from elsewhere, which grants console privilege to my ssh session. Then I log out of the console, and wait for someone else to login, whereupon I pounce, using my ssh session with it's enhanced privileges. After all, groups are processed at login, so removing me from "console" at console logout leaves hanging privileges for my ssh session.

I think that there is something to be said for a daemon to handle console privilege/authentication for me. I won't argue with your point that *kit is horrible at the architectural and specification level, but I see the need for some-such service. Thought... a daemon listening on a Unix socket or named pipe, and give me access to the socket. Perhaps chown the pipe to me, and keep group access for itself, in it's own single-user group. Kill the socket/pipe when my session ends. Obviously doesn't fall-off-a-log work for multi-seat or fast-user-switching, or whatever that's called. But in 5 seconds I think of a socket/pipe per console user, etc.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
saellaven
Guru
Guru


Joined: 23 Jul 2006
Posts: 486

PostPosted: Fri Jun 13, 2014 8:00 pm    Post subject: Reply with quote

eccerr0r wrote:

And why, if systemd is so bad, is basically all major Linux distributions adopting it? Obviously if it's bad, everyone would simply not use it. But even Debian uses it now. It's the popular distribution devs that end up determining pervasiveness; if they think it's that bad, they shouldn't include it at all, option or not. Is Gentoo a fencesitter like me for the most part?


It's the path of least resistance, being pushed from the biggest behemoth in the Linux world, which long ago absorbed most of the developers doing core system work... in effect, Red Hat is largely the Linux upstream and most distros can't keep up with the patches required to deal with RH's upstream push for systemd.

It's adoption isn't about being bad or good or that it's unstable alpha quality software that routinely breaks despite being central to a system, but about being able to be lazy... hey, everyone else is doing it, who cares if it completely undermines the point of having a separate distro?
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Jun 13, 2014 9:21 pm    Post subject: Reply with quote

eccerr0r wrote:
Syscalls require root permissions,

No they don't. Every file opened results in a syscall by libc on your behalf.

Before we go into the specifics, I'd like to point out that was in reference to:"at root it's just another form of IPC to pass data between kernel and DE without expensive forking". With respect, that sentence makes no sense at all from where I'm sitting.
Quote:
and you need to fork an SUID process to get those permissions, hence IPC is faster to get at privileged routines (and dbus just uses the there-since antiquity Unix sockets anyway, and they are shareable, bidirectional, and maintain UID/GID).

Yes you're talking about a daemon: I don't have an issue with daemons, as such.

I note in passing that it's using a form of IPC, to talk to other processes via the kernel; it isn't one in and of itself. Effectively it's a multiplexor, and a single-point of failure.

Also, for the last few years we've had capabilities, which can be attached to a process.
Quote:
So what do you propose as a non-fork method that safely allows any console user, regardless of DE, to do power operations and still prevent remote users who can walk up to the console or screen sessions initiated from the console from doing the same?

Isn't the whole point that X is controlling the display and the keyboard, and the DM is talking a defined protocol to X? Thus we had depontious stating that it's the DE which knows who's at the console.

If we take that as a given, then again, the point remains: why does any other user matter? Or more to the point, why does any other process matter?

You mention "remote users walking up to the console"; to me that's not a remote user, by definition.
Quote:
Honestly I really don't care one way or the other. There are benefits to both and certainly not an issue for a predominantly single-user-on-console computer.

The point is the "multi-user-switcharoo" has been shown to be busted. So extant methods are to be preferred, including simply locking the screen, and timing out the session after a certain period of time, if the admin configures it like that. For that multi-user setup.

All of which can be done at DE/DM level, and much more simply. Without, and here's the rub, impinging on the simpler use-cases, nor making them any more complex, because that's not such a great basis to build custom rollouts on.

So the standard user, with a desktop and laptop perhaps shared between a few users, who let's not forget, was supposedly who all this was aimed at, doesn't have to go keep going through pointless "innovations" just to do the same thing they could do 10 years ago, only not as simply.
Quote:
And it's not the distribution packager's fault for certain applications that require any particular package, it's all upstream.

Eh? I never said anything about required dependencies.

If you mean profiles, and not pretending that a crippled fork designed to be subsumed into systemd is the same package as before (and let's pull systemd on non-systemd profiles), then to me that's just basic sense. It's also what was agreed upfront; but then, so was udev continuing to build as before.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Jun 13, 2014 9:33 pm    Post subject: Reply with quote

depontius wrote:
My issue here is that once we get to non-root X, neither the DM nor the DE will be running root. The DM will probably be running as nobody, though perhaps it will run as "dmuser", and the DE will be running as me. At that point neither is privileged, though the DM might look a little more special, in terms of being granted extra privilege.

Yes, we could even call that a "capability". ;)

Though I'd argue a DM is a bit like agetty/login combined: it's supposed to be able to log you in and that requires being able to su to your uid. Traditionally it's supposed to be a slimline affair, and audited for security for precisely that reason.
Quote:
I don't really see how simple groups do the job. This isn't just suspend, hibernate, shutdown, and reboot. It's also cdrom and usb access, since those are also associated with the console. As someone else, perhaps even you have said, the console user simply needs that level of basic access, or they could push the power button (for 30 sec) to do what they can't do on-screen. Even an idea like just-in-time group updates - add me to "console" just before my console session is turned over to me - doesn't really hack it. Groups are processed at login, hence the need to add me prior to handing me the session. But let's say my console session is hung - then my being able to ssh in and have console privilege is good - it will let me get out of trouble. But let's say I'm evil - I login at the console, then ssh in from elsewhere, which grants console privilege to my ssh session. Then I log out of the console, and wait for someone else to login, whereupon I pounce, using my ssh session with it's enhanced privileges. After all, groups are processed at login, so removing me from "console" at console logout leaves hanging privileges for my ssh session.

I must be tired, but I really can't follow that, sorry. It's perfectly possible to query and know who's logged in where, and I really don't have any problem with you running a daemon for that. It sounds an awful lot like the operating system to me though, since that's where we get the info from. Not sure it's necessary: for instance someone in wheel has that membership precisely so they can override the normal state of affairs, and this:
Quote:
I think that there is something to be said for a daemon to handle console privilege/authentication for me. I won't argue with your point that *kit is horrible at the architectural and specification level, but I see the need for some-such service. Thought... a daemon listening on a Unix socket or named pipe, and give me access to the socket. Perhaps chown the pipe to me, and keep group access for itself, in it's own single-user group. Kill the socket/pipe when my session ends. Obviously doesn't fall-off-a-log work for multi-seat or fast-user-switching, or whatever that's called. But in 5 seconds I think of a socket/pipe per console user, etc.

What's the difference between that, and calling that daemon the DM?

After all it's managing the "seat", isn't it?
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6935
Location: almost Mile High in the USA

PostPosted: Sat Jun 14, 2014 12:00 am    Post subject: Reply with quote

steveL wrote:
eccerr0r wrote:
Syscalls require root permissions,

No they don't. Every file opened results in a syscall by libc on your behalf.

Before we go into the specifics, I'd like to point out that was in reference to:"at root it's just another form of IPC to pass data between kernel and DE without expensive forking". With respect, that sentence makes no sense at all from where I'm sitting.

We're using IPC to bring into userspace what cannot be done by a unprivileged account. Suppose I want to run a syscall to suspend/shutdown the machine. Now, does it not need root privileges to run those syscalls? Of course they do, not sure how it could be misinterpreted as not requiring root to do these power syscalls. How do you run a privileged syscall after losing root privileges? Fork a setuid process.

Quote:
Quote:
and you need to fork an SUID process to get those permissions, hence IPC is faster to get at privileged routines (and dbus just uses the there-since antiquity Unix sockets anyway, and they are shareable, bidirectional, and maintain UID/GID).

Yes you're talking about a daemon: I don't have an issue with daemons, as such.

I note in passing that it's using a form of IPC, to talk to other processes via the kernel; it isn't one in and of itself. Effectively it's a multiplexor, and a single-point of failure.

Also, for the last few years we've had capabilities, which can be attached to a process.

A multiplexor is a good thing, you can have multiple methods to do what you want to do and they all can communicate with each other on their intent. The kernel itself is multiplexing lots of things, and we don't worry about it being a single point of failure? Also do we really want to fine grain every application to be allowed or not to shutdown the system? I think it'd be better to have the console user, regardless of application they're using, be allowed to shutdown the machine.
Quote:
Quote:
So what do you propose as a non-fork method that safely allows any console user, regardless of DE, to do power operations and still prevent remote users who can walk up to the console or screen sessions initiated from the console from doing the same?

Isn't the whole point that X is controlling the display and the keyboard, and the DM is talking a defined protocol to X? Thus we had depontious stating that it's the DE which knows who's at the console.

If we take that as a given, then again, the point remains: why does any other user matter? Or more to the point, why does any other process matter?

You mention "remote users walking up to the console"; to me that's not a remote user, by definition.

It matters because only power/(mount, etc.) commands that are actually spawned at the console are allowed to play with the power routines and these need privileges. The DM drops root privileges before starting the DE so we no longer have control over what that user can and can't do. A suid solution will give those privileges back, but it's possible to keep them longer than needed. One way to clean things up is to make sure that user has all processes cleaned up on logout, but there are very distinct reasons why that user should be able to leave detached jobs upon logout - but these processes must lose "console" privileges but maintain user privileges as if they were a remote user. This is the distinction you don't seem to be understanding - by the physical location of the user at the time of executing the command, they should have different rights. They should not have the rights once they are gone from the console (but the "default" user by the DM should also have the rights of shutting down the machine too!).
You can see that Windows did it right, remote desktop does not have the "shutdown" command like if you logged in from console. Of course if you have administrator access then all bets are off and will trump the console user.
Quote:
Quote:
And it's not the distribution packager's fault for certain applications that require any particular package, it's all upstream.

Eh? I never said anything about required dependencies.

If you mean profiles, and not pretending that a crippled fork designed to be subsumed into systemd is the same package as before (and let's pull systemd on non-systemd profiles), then to me that's just basic sense. It's also what was agreed upfront; but then, so was udev continuing to build as before.

The whole point of this thread is why we (as users of Gentoo) should put up with systemd to begin with. Gentoo, agreeably, has no control over what the upstream software packagers do with their software - in the case of Gnome3, Gnome3 says they want systemd, so Gentoo says we need systemd.

If you take a look at other distributions out there, especially Debian that actually is willing to hack and do nasty backports to keep old software running as witnessed by one heck of a lot of software out there with Debian fingerprints on them. Agreeably this is a lot of work, but even Debian even caved in systemd.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2850
Location: Bay Area, CA

PostPosted: Sat Jun 14, 2014 8:40 am    Post subject: Reply with quote

Running into this now. I have removed upower and installed upower-pm-utils but world update is trying to pull in upower because of gnome-base/gnome-settings-daemon and gnome-extra/gnome-power-manager.

Whatever happened to that virtual thingy someone was talking about? Why is gnome still trying to pull upower when upower-pm-utils is emerged and is providing all that upower will provide? I thought this was perfect for a virtual/upower. Why is it not there yet?
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2850
Location: Bay Area, CA

PostPosted: Sat Jun 14, 2014 8:45 am    Post subject: Reply with quote

well well well! gnome-base/gnome-settings-daemon-3.12.2 doesn't build with upower-pm-utils, so there goes the virtual thingy.

Code:
configure: error: Package requirements (gio-unix-2.0 libpulse >= 2.0 gudev-1.0 libpulse-mainloop-glib >= 2.0 libcanberra-gtk3 upower-glib >= 0.99.0) were not met:

Requested 'upower-glib >= 0.99.0' but version of upower-glib is 0.9.23
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6620
Location: Austria

PostPosted: Sat Jun 14, 2014 9:42 am    Post subject: Reply with quote

devsk, no one said upower-pm-utils would work universally for everyone. When you're using packages that simply require newer upower, of course, you are out of luck. And using gnome you have among the best chances to be hit by that.

Code:
$ grep -C1 upower /usr/portage/gnome-base/gnome-settings-daemon/gnome-settings-daemon-3.12.2.ebuild
>=media-sound/pulseaudio-2
>=sys-power/upower-0.99
x11-libs/cairo

upower-pm-utils: ebuild says no...
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2850
Location: Bay Area, CA

PostPosted: Sat Jun 14, 2014 3:55 pm    Post subject: Reply with quote

It is such a mess man. systemd has penetrated deep in the system (which other distros depend on) but without any regard for what the distros will do with the services. For example, do we have full support for systemd in Gentoo i.e. every init runscript has an equivalent systemd service files. I am very sure Richard Yao has not created a systemd service for ZFS init script he has now. So, I am pretty sure I am unbootable if I go systemd instead of openrc.

Just in Dec '13 I had faced this issue with suspend and hibernate missing from the KDE completely because of upower and systemd marriage. And now its broken again for KDE unless I go with upower-pm-utils and then I have no way to build gnome. It took me several days to figure things out and fix it in Dec '13 and now I don't even have a way out.

So, what do I do when I need both gnome and kde on one system image? I have one user who likes KDE and another who likes gnome. Both laptops boot the same squashfs image. I am SOL'd.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Jun 14, 2014 5:34 pm    Post subject: Reply with quote

eccerr0r wrote:
steveL wrote:
Every file opened results in a syscall by libc on your behalf.

Before we go into the specifics, I'd like to point out that was in reference to:"at root it's just another form of IPC to pass data between kernel and DE without expensive forking". With respect, that sentence makes no sense at all from where I'm sitting.

We're using IPC to bring into userspace what cannot be done by a unprivileged account.

OK, I get you there: nonetheless you don't need to fork to talk to the kernel. I stress this because of the whole "kernel is a single-point of failure" argument below, and because it matters.
Quote:
Suppose I want to run a syscall to suspend/shutdown the machine. Now, does it not need root privileges to run those syscalls? Of course they do, not sure how it could be misinterpreted as not requiring root to do these power syscalls. How do you run a privileged syscall after losing root privileges? Fork a setuid process.

Or run a daemon to execute commands for you, or pass back an fd so you can access something you couldn't otherwise, sure.

The question is why the DM can't do that for you; since you're talking about "pass[ing] data between kernel and DE".
Quote:
Quote:
Yes you're talking about a daemon: I don't have an issue with daemons, as such.

I note in passing that it's using a form of IPC, to talk to other processes via the kernel; it isn't one in and of itself. Effectively it's a multiplexor, and a single-point of failure.

Also, for the last few years we've had capabilities, which can be attached to a process.

A multiplexor is a good thing, you can have multiple methods to do what you want to do and they all can communicate with each other on their intent. The kernel itself is multiplexing lots of things, and we don't worry about it being a single point of failure?

I feel like we're exploring the reasons to have a kernel.

The kernel is not a single-point of failure, since literally every process and thread, will at some point or another run in kernel context (ie run the kernel). That's where scheduling and priority decisions kick in (immediately from the pov of userspace.) It also has its own kthreads.

All of these are running the same code, crafted over decades by people who effectively threw out the "crazy userspace" "developers" you want us to "cave in" to.
Quote:
Also do we really want to fine grain every application to be allowed or not to shutdown the system? I think it'd be better to have the console user, regardless of application they're using, be allowed to shutdown the machine.

"We don't want every application to be allowed to shutdown or suspend the machine, since the ability is a security point; let's just let any (locally) logged-in user do that with whichever application they like."

Can you not see the contradiction?
Quote:
Quote:
Isn't the whole point that X is controlling the display and the keyboard, and the DM is talking a defined protocol to X? Thus we had depontious stating that it's the DE which knows who's at the console.

If we take that as a given, then again, the point remains: why does any other user matter? Or more to the point, why does any other process matter?

You mention "remote users walking up to the console"; to me that's not a remote user, by definition.

It matters because only power/(mount, etc.) commands that are actually spawned at the console are allowed to play with the power routines and these need privileges. The DM drops root privileges before starting the DE so we no longer have control over what that user can and can't do.

Yes but the DM can still do things, and it can listen only to the DE, because it started it, so it knows its pid, and it's notified when it exits or is stopped.

I'm not sure what "we no longer have control" is meant to mean; the admin is always in charge, or YDIW. Further as you just stated, we've dropped privilege, so the user is most definitely limited in what they can do: by the OS, as it should be.

Nor do I understand the point about "safely allow any console user, regardless of DE, yet still prevent remote users who can walk up to the console" since they appear to be the same thing.
Quote:
A suid solution will give those privileges back, but it's possible to keep them longer than needed. One way to clean things up is to make sure that user has all processes cleaned up on logout, but there are very distinct reasons why that user should be able to leave detached jobs upon logout - but these processes must lose "console" privileges but maintain user privileges as if they were a remote user. This is the distinction you don't seem to be understanding - by the physical location of the user at the time of executing the command, they should have different rights. They should not have the rights once they are gone from the console (but the "default" user by the DM should also have the rights of shutting down the machine too!).

Yeah I appreciate that I didn't address the user logged in at a physical tty; and I see what you're saying in that regard vs someone logged in remotely over ssh.

The problem I have is that I feel it's conflating different domains, and taking a false premise in one to mean something different in another. Then we get this awful mess of competing "requirements", and "let's just let a daemon worry about it" instead of thinking it through.

For instance, a lib function to ask "is this uid a locally-logged in user?" seems a lot simpler to me, if it's not been done already, and one that would have wider-applicability. Then the questions of "is that enough?" can be answered in the specific domain; anything to do with the desktop doesn't even need it, since the DM is privileged by definition, or it cannot log you in, and it is also in a special relationship with the X server that it started, which has direct hardware access.

IOW in the GUI app area, no app requires the ability to shutdown or hibernate the machine. The user requires the ability to allow certain apps to notify the DE that they don't want the display blanked (for ex) as they have started playing video. The app does that unconditionally using a call supplied as part of the DE toolkit, since every GUI app is built using a toolkit; assuming it's not being compiled for a minimal embedded setup (or sth). The configuration merely determines whether the DE actually cares. But again, it's down to the configuration, at the DE level, not down to the individual app or where it happens to be running. That puts the control back where it belongs: with the user or admin.

So we're starting to narrow down requirements, and I concur that an app like shutdown or hibernate is a point of privilege. It seems to be the non-GUI mode, which can be simply when we're not running as root/have the SYS_ADMIN capability (so non-privileged), really just needs to know that it has a controlling tty, the tty is a logged-in user process, and the terminal it's logged in at is local (thus not a remote shell). Isn't there stuff in pam for this? If not, it's hardly that difficult, and look ma: no daemons, just a minimal library routine since we have an OS.

Or one could simply restrict the ability to do shutdown and hibernate to the power group, and add wheel to that group. I prefer that approach myself, since I don't in general want just anyone to shutdown and hibernate from the terminal, even if they could switch the machine off: that's easy enough to handle with acpi, so that your filesystems are properly umounted. And if someone is in wheel, then they can do what they want, even if they are logged in remotely, since that's the whole point of the group (once you visudo.)
Quote:
You can see that Windows did it right, remote desktop does not have the "shutdown" command like if you logged in from console. Of course if you have administrator access then all bets are off and will trump the console user.

Yes but Windows does exactly what I discussed: the DM is root, and there are no console logins to worry about. OFC the DM happens to be considered part of the kernel in Windows, which leads to all sorts of unpleasant situations.

IOW it's at the DM level, not the "where did this process come from" level; the DM is running a remote login, so it doesn't give the option.

If you keep it at DM level for GUI apps, it's much easier to do a similar thing on Linux.
Quote:
Quote:
Quote:
And it's not the distribution packager's fault for certain applications that require any particular package, it's all upstream.

Eh? I never said anything about required dependencies.

If you mean profiles, and not pretending that a crippled fork designed to be subsumed into systemd is the same package as before (and let's pull systemd on non-systemd profiles), then to me that's just basic sense. It's also what was agreed upfront; but then, so was udev continuing to build as before.

The whole point of this thread is why we (as users of Gentoo) should put up with systemd to begin with.

No it's not: it's about whether we're being pushed to use systemd even when we don't want to (and is this latest move to pull in systemd when it's not wanted indicative of that). Seems pretty self-evident to me that we are, in line with upstream's plan to "gently push" people into using systemd via the various distros' dependency-trees. Like any other missionaries, they believe this is in our interest, and that they know better than us what we need, since they're the "experts."

Some of us feel they don't know what they're doing, and would rather stay out of it; unfortunately we're not given the choice to do that without confronting the Plan. That's the trouble with the whole "you're either with us, or you're against us" mentality of zealots: it forces people to take sides, thus it is divisive, and I for one don't want Linux to be divided and conquered.

As I said, it's not force though; it just feels like it when your previously-working choices are taken away from you.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Jun 14, 2014 5:47 pm    Post subject: Reply with quote

devsk wrote:
Just in Dec '13 I had faced this issue with suspend and hibernate missing from the KDE completely because of upower and systemd marriage. And now its broken again for KDE unless I go with upower-pm-utils and then I have no way to build gnome. It took me several days to figure things out and fix it in Dec '13 and now I don't even have a way out.

So, what do I do when I need both gnome and kde on one system image? I have one user who likes KDE and another who likes gnome. Both laptops boot the same squashfs image. I am SOL'd.

I thought there was KDE-systemd profile? In any event I thought KDE worked with systemd.

Doesn't help with zfs initscripts, but I'm sure those will come soon enough.

But yeah, linux-systemd is effectively it's own base distro; that's the intent of it.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6935
Location: almost Mile High in the USA

PostPosted: Sat Jun 14, 2014 6:50 pm    Post subject: Reply with quote

steveL wrote:

Quote:
Also do we really want to fine grain every application to be allowed or not to shutdown the system? I think it'd be better to have the console user, regardless of application they're using, be allowed to shutdown the machine.

"We don't want every application to be allowed to shutdown or suspend the machine, since the ability is a security point; let's just let any (locally) logged-in user do that with whichever application they like."

Can you not see the contradiction?

There is no contradiction. By using cgroups you are implicitly telling which applications the user is allowed to run (namely, what is forked from the DM). There needs to be an application agnostic API that allows these privileged commands that simply depends on being physically at the console.

And again I don't understand why there is confusion about issues between remote users should NOT have permissions to reboot the machine. As long as they stay remote, they should not be able to do these power operations. If they feel the need to physically relocate themselves to the console, they should then be allowed to reboot the machine. Simple as that. The whole premise is whether they are at console or not, no dependencies on software, no dependencies on DM or DE, they should be able to reboot at console. BUT if they are NOT at the console, they should NOT have these privileges either.
Quote:
The problem I have is that I feel it's conflating different domains, and taking a false premise in one to mean something different in another. Then we get this awful mess of competing "requirements", and "let's just let a daemon worry about it" instead of thinking it through.

For instance, a lib function to ask "is this uid a locally-logged in user?" seems a lot simpler to me, if it's not been done already, and one that would have wider-applicability. Then the questions of "is that enough?" can be answered in the specific domain; anything to do with the desktop doesn't even need it, since the DM is privileged by definition, or it cannot log you in, and it is also in a special relationship with the X server that it started, which has direct hardware access.

[bunch of pam and legacy stuff so there's less scrolling]

Yes these things have been solved before by these kinds of hacks, but isn't it time to move on? An issue with the fork based authentication/shutdown is that once things are passed into the "helper app" that has the permissions of pam, etc.; is that it can only provide fixed feedback and the DE (or other user-space application) cannot freely represent feedback information if something failed other than by perhaps a return code. For things that can take time, the IPC can return generic status information that the DE can draw out whatever way it wants. Perhaps the operation requires user intervention but needs root to start? With an IPC solution it can still have the look and feel of the DE instead of being forced to have whatever the suid application gives you. Or it can totally ignore it for a console application.
Quote:
As I said, it's not force though; it just feels like it when your previously-working choices are taken away from you.

Sometimes it feels like it's a "GET OFF MY LAWN" syndrome going on here. It's not like I haven't had to deal with choices the Gentoo devs had made - I despise them as well, such as maintaining apache1 and running gnome2, but in order to keep a working system, just like many other things in life: keep up or die... Apache2 and gnome3 bought me absolutely nothing...except bugfix updates no longer are available for Apache1 and Gnome2. Alas I've now grown accustomed to Apache2, and though admittedly I haven't totally warmed up to Gnome3, the ability to emerge --update world once more outweighs the pain...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6 ... 18, 19, 20  Next
Page 5 of 20

 
Jump to:  
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