| View previous topic :: View next topic |
| Author |
Message |
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
 Posted: Fri Sep 19, 2014 11:14 am Post subject: Do I need PAM? [solved] |
 |
|
I updated my box after one month.
Regarding xscreensaver i came over an use flag called PAM.
After disabling it globally and rebooting i did not found any drawbacks removing PAM and udisks.
My question:
do i really need pam? udisks? pulseaudio(pulled in by other packages and causes circular dependencies)?
I get the impression that there are lots of packages pulled in with little added value.
It Is more a question about curiousity than a rant or flame post
I use i3wm and not mostly google-chrome. i ust saw spidermonkey fails to build and nemo crashes on startup.
spidermonkey fails to build on t4400 cpu whatever i try to do, and nemo just builds but crashes on startup. well i am not that eager to solve those, as google-chrome works and network works too.
Last edited by Roman_Gruber on Sun Sep 21, 2014 12:13 pm; edited 1 time in total |
|
| Back to top |
|
 |
charles17
Advocate
Joined: 02 Mar 2008
Posts: 3664
|
| Posted: Fri Sep 19, 2014 11:22 am Post subject: Re: Do I need PAM? |
|
|
At least I don't have it, sys-auth/pambase not installed. And it would be pulled in only optionally by some few packages. | Quote: | $ grep pam /etc/portage/package.use
media-sound/jack-audio-connection-kit -pam
net-mail/mailbase -pam
net-misc/openssh -ldap -pam
net-print/cups -ldap -pam
sys-apps/busybox -pam
sys-apps/kbd -pam
sys-apps/openrc -netifrc -pam
sys-apps/shadow -pam
sys-apps/util-linux -pam
sys-libs/libcap -pam
x11-apps/xdm -consolekit -pam |
|
|
| Back to top |
|
|
Melsion
n00b
Joined: 01 Nov 2007
Posts: 34
|
| Posted: Fri Sep 19, 2014 12:49 pm Post subject: |
|
|
| Interesting question, I thought it was necessary for logging in through kdm and openssh, is it really not necessary? What's its function then? |
|
| Back to top |
|
|
santy_in
n00b
Joined: 28 May 2014
Posts: 9
Location: India
|
| Posted: Fri Sep 19, 2014 12:58 pm Post subject: |
|
|
Well I use KDE and i have pam and udisk as global use flag. Moving to your query:
Do you need PAM?:
I think it depends on you whether you want it or not probably in most cases.
If you don't have PAM, the system authentication will be simple as in matching the encrypted code of your password stored in /etc/passwd, unless you have another mechanism to authenticate and for the applications which requires some kind of authentication will have to use their own. But if you do have the PAM neither you(system) nor the applications need to worry about the authentication on their own and of course you will have an extra layer of security.
As charles17 pointed out one : | Code: | | net-misc/openssh -ldap -pam |
. I have installed openssh with PAM, it doesn't make much difference except teaching me how to write a good password depending on the modules.
DO you need UDisk?:
It is needed particularly when you have a desktop environment.
Last edited by santy_in on Tue Sep 23, 2014 8:58 pm; edited 1 time in total |
|
| Back to top |
|
|
charles17
Advocate
Joined: 02 Mar 2008
Posts: 3664
|
| Posted: Fri Sep 19, 2014 1:58 pm Post subject: Re: Do I need PAM? |
|
|
| tw04l124 wrote: | After disabling it globally and rebooting i did not found any drawbacks removing PAM and udisks.
My question:
do i really need pam? |
Can't find again the reference but somewhere I've read that on a single user computer there is no benefit from running PAM.
Maybe some of gurus could shed some light on this question? |
|
| Back to top |
|
|
Perfect Gentleman
Veteran
Joined: 18 May 2014
Posts: 1249
|
| Posted: Fri Sep 19, 2014 2:06 pm Post subject: |
|
|
| Using KDE and KDM, just now recompiled world without pam and ldap, everything works. |
|
| Back to top |
|
|
creaker
l33t
Joined: 14 Jul 2012
Posts: 651
|
| Posted: Fri Sep 19, 2014 2:55 pm Post subject: |
|
|
| Quote: | | do i really need pam? udisks? pulseaudio(pulled in by other packages and causes circular dependencies)? |
They are just another one source of headaches. Haven't installed neither pam, nor udisks, nor pulseaudio. As well as tons of other "highly recommended" packages - upower, consolekit etc... |
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Fri Sep 19, 2014 6:05 pm Post subject: |
|
|
As others have said, the answer is do you need it?
Although, fundamentally pam exists to circumvent the UNIX permission system, so I say good riddance to it. Udisks seems to be mostly used for suspend to ram or disk operations and pulseaudio is just puzzling. 99% people have no use for 99% of the features it uses, so you probably won't miss it if you switch to straight alsa.
Well over a year ago I had KDE installed *kit-less and pam-less and it ran just fine, if unsupported by $upstream.
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Fri Sep 19, 2014 6:05 pm Post subject: |
|
|
nemo is on a dying end, that gnome derived junk slowly kills itself with random crashes and dependencies which pulls in too much packages which are only needed for one user application.
anything else works.
Thanks for the answers so far. On my second box I can try out things and I do not have to worry about it much. It is just a second screen for myself.
It gets more difficult these days to have a small desktop environment without much of those kits. |
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Fri Sep 19, 2014 6:09 pm Post subject: |
|
|
| tw04l124 wrote: | | It gets more difficult these days to have a small desktop environment without much of those kits. |
I've found it is much more functional to ditch the big name ones that try to compete with windows or mac. Something like i3, openbox, awesome, etc. takes a bit of work to set up, but is much lighter on the dependencies and generally easier to mold to fit your workflow.
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Fri Sep 19, 2014 6:16 pm Post subject: |
|
|
| i3wm works decent, its in portage as i3 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Sep 19, 2014 6:20 pm Post subject: |
|
|
| The Doctor wrote: | | i3, openbox, awesome, etc |
Don't miss fvwm, especially fvwm-crystall, if you still want luxury. Works perfectly nice and free of *-kit (especially policykit) and pam. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Sep 19, 2014 10:32 pm Post subject: |
|
|
I'll take pam over policykit, any day (and yes I know policykit "works with" pam, thx.)
To my mind pam is one of those things that's useful in the overall mix, but in comparison to many things, it's not something an admin should tweak lightly, or even willingly. Either rely on your distro, disable it, or in the cases where you're not a home user, hire an admin who knows what they're doing.
ldap is much less useful for the general user, though it is sometimes needed for Windows AD interop. Thing is if you're doing that, just having the ldap flag isn't enough, afair. And if you're on a network with LDAP, chances are you're using it already; but the general home user isn't really helped by that flag defaulting on, imo. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Sep 20, 2014 6:45 am Post subject: |
|
|
| steveL wrote: | | I'll take pam over policykit, any day (and yes I know policykit "works with" pam, thx.) |
I agree with your opinion: pam has its uses.
However, if you are a home user, you most probably won't need it, and then it is just an additional layer of complexity, possibly providing an attack vector.
| Quote: | | ldap is much less useful for the general user, though it is sometimes needed for Windows AD interop |
In a home net? Do you mean in connection with samba?
So far, I installed ldap only because acroread won't allow me to do annotations without it. That's a pityful behaviour of acroread, but unfortunately there is no substitute yet. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Sep 21, 2014 12:15 am Post subject: |
|
|
| mv wrote: | I agree with your opinion: pam has its uses.
However, if you are a home user, you most probably won't need it, and then it is just an additional layer of complexity, possibly providing an attack vector. |
Yeah, but we have to consider these things relatively; if you actually need to be able to configure and tweak user/app permissions after they've been compiled, and with more complexity than standard user grouping allows, then PAM really is it.
I'd very much hope that the default Gentoo pam config doesn't have holes in it; afaict it's okay, and I'm sure people would have complained/patched before now if so. You're right that a person who doesn't know what they're about (and I include myself in that) can easily slip up and effectively allow anyone in with a seemingly innocuous change, but that's the whole point of root privilege.
I guess my point really is that PAM does everything we could possibly want, in terms of decoupling permission from code, thus allowing the admin to manage those things, and the developer simply to use libpam when the code is configured to do so (usually via the same backend shim across projects), and not to worry about it otherwise. Of course, sudo and visudo are a better interim before you get that far, imo, and there's no reason we can't use both.
So I don't see the point in policykit at all. Apparent ease is not enough to convince me that any Unix system should rely on javascript for core authentication, and afaic you can mess up your policykit setup just as badly, just as easily. For something like auth, I'd much rather we have PAM, and let real admins be responsible for it. 99% of end-users aren't going to change anything anyhow.
So sure, disable it by all means; just don't get suckered into believing that policykit is needed.
| Quote: | | Quote: | | ldap is much less useful for the general user, though it is sometimes needed for Windows AD interop |
In a home net? Do you mean in connection with samba? |
Eh, god this is from years ago; needed to setup openldap and kerberos in order to integrate a PostNuke(+phpbb3) instance with Windows AD. It worked lovely in the end, so users could login and register with AD account and password, which we never stored at all, simply sent over the (encrypted) wire to AD. Only thing we stored was SAMAccountName (however it's spelt) for the nick/uid. Lisa was actually bloody useful to find out about the topology (afair that was samba.)
So not home use, there, but I thought AD was integrated with Windoze OS thereafter; tbh I got out of doing anything against Windows shortly after that, though. Life's far too short ;-)
| Quote: | | So far, I installed ldap only because acroread won't allow me to do annotations without it. That's a pityful behaviour of acroread, but unfortunately there is no substitute yet. |
Heh yeah, that is a bit lame. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Sep 21, 2014 7:05 am Post subject: |
|
|
| steveL wrote: | | if you actually need to be able to configure and tweak user/app permissions after they've been compiled |
I am not sure why one would need this as a home user. In fact, except for ldap authorization or perhaps special authorization devices (voice recognition, fingerprint etc.), I have no idea why one should need pam. (OK, recently I learnt that systemd relies on a pam module hacking up its cgroups, but this is just a hack to repair a broken concept.)
In fact, the current discussion caused me to check all my packages with optional pam support, and I realized that for many things I have no idea what it should be good for. Here is a list
| eix --installed-without-use pm -# wrote: | # I thought the first group is clear:
# Possibly use ldap/hardware instead of shadow user password.
# However, why isn't sys-apps/shadow sufficient for this?
app-admin/sudo
app-misc/screen
net-misc/openssh
net-misc/openvpn
net-print/cups
sys-apps/busybox
sys-apps/shadow
sys-apps/util-linux
x11-misc/slim
x11-misc/xlockmore
x11-misc/xscreensaver
# Why would the following mail/connection software need pam?
# Moreover, if this is a "mail" standard, why not in firefox, pine?
mail-client/claws-mail
net-dialup/ppp
net-firewall/ipsec-tools
net-im/jabberd2
net-libs/c-client
net-libs/wvstreams
net-mail/mailbase
# The following is completely mysterious to me:
sys-apps/kbd
sys-apps/openrc
sys-libs/libcap |
| Quote: | | just don't get suckered into believing that policykit is needed. |
I hope that my remark could not be understood this way: I dislike policykit much more than systemd because of its security threat. In fact, I do not see much relation between policykit and pam at all: Policykit is mainly about giving access to all /dev/... files if it is used instead of accessing the files directly. This is completely orthogonal to what pam does and is more about ignoring the permissions of the unix file system than anything else.
| Quote: | | I'd very much hope that the default Gentoo pam config doesn't have holes in it |
My concern about anytihing running with root privileges is not so much a mistake in the configuration (although also this is much simpler to mess up with policykit than with pam), but more about bugs in the code itself: race conditions, array overflows, pointers to free memory, ... simply each line of code is a potential thread: The code running with root privileges should be kept as small as possible. |
|
| Back to top |
|
|
charles17
Advocate
Joined: 02 Mar 2008
Posts: 3664
|
| Posted: Sun Sep 21, 2014 10:51 am Post subject: |
|
|
| mv wrote: | | steveL wrote: | | I'll take pam over policykit, any day (and yes I know policykit "works with" pam, thx.) |
I agree with your opinion: pam has its uses.
However, if you are a home user, you most probably won't need it, and then it is just an additional layer of complexity, possibly providing an attack vector. |
A clear recommendation like "If you dont't know if you need it you don't need it" should go into a new section "Who needs it, what is good for?" on https://wiki.gentoo.org/wiki/PAM
Most 'home users' like me are only getting confused by such brilliant admin tools. |
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Sun Sep 21, 2014 12:12 pm Post subject: |
|
|
Okay nice.
Well only xscreensaver pulls it in, and therfore compiling pam only for a lock screen is nuts.
I also do not get the thing to make bloatware for somethign which is just to check a file and compare it with the provided passwords checksum.
I read the wiki article but i do not see any benefit except to annoy the user. It sounds like on those windoze boxes when you are annoyed to provide a new password every week and other junk.
funny how they say it is a feature that it is modular. I see it as junk, because you can call pam or hardcode it in the app. considering it is only a line to compare a checksum with the given password i see pam now as uneeded bloatware on a desctop box. |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Sep 21, 2014 4:41 pm Post subject: |
|
|
| tw04l124 wrote: | | I see it as junk, because you can call pam or hardcode it in the app |
It is not that simple: First of all, an app without permission is not able to read the shadow file.
Moreover, giving a whole app root just to read that file is certainly not a good idea, either.
The checksum comparison should also be written by a security expert so that e.g. no traces are left in memory which might be examined by non-privileged programs.
Last, but not least: If you do not use shadow but something like ldap or another mechanism, it is certainly not a good idea to code everything in each app.
In fact, libraries are there to be used commonly and not coded separately for each program.
That being said, the better question is: Do you really need a screenlocker for a home system which uses the user's password?
That is, do you need actually anything of what pam provides?
If your answer is negative, then you do not need pam. Otherwise, removing pam and relying on unprofessional ad-hoc solutions in several binaries is a two-sided sword - it is hard to predict what is the more secure solution. |
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Sun Sep 21, 2014 4:43 pm Post subject: |
|
|
Thanks you made a point here  |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Sep 22, 2014 6:38 am Post subject: |
|
|
| mv wrote: | | steveL wrote: | | if you actually need to be able to configure and tweak user/app permissions after they've been compiled |
I am not sure why one would need this as a home user. |
And I am not sure why you keep banging on about home use as if that's the only usage that exists ;) when I've explicitly said above that much of this discussion is about network use, and there's an "if" attached to the statement you've chopped out of context. As I said, these things are relative. But policykit is nuts however you look at it, imo at least.
WRT your list, individual apps typically install their own configuration file for pam, so that each program can be configured separately, even if by default they all use the same base-system setup. And ofc that means they have to link to the library, in order to use it, and actually use it as well; so it does add a dependency, however you look at it.
Naturally the conf file is something a distro can tweak/replace, and the separation of concern works; which is the overall point I alluded to before.
There is overlap between sudo/shadow and pam, discussed in the documentation (manpages afair, though), here (LFS shadow) and on this page; the latter set is quite useful for config, if a bit messy.
| Quote: | # Why would the following mail/connection software need pam?
# Moreover, if this is a "mail" standard, why not in firefox, pine?
mail-client/claws-mail |
Dunno I use mutt ;-) I gave claws a lookover when I reviewed the options when switching from KMail, but I don't recall much about it, beyond it doesn't do Maildir properly (and nor does anything else GUI.) Or didn't at that time anyhow.
Checking eix -e claws-mail doesn't show pam USE flag here, though I could be behind tree.
For the last 3, if you care, check the code. I'd certainly expect a professional developer to know enough about PAM to be able to code against it, when required, though hopefully not comfortably as a) you should never feel comfortable when working on security-sensitive code ;) and b) it really is aimed at admins, so I'd expect a programmer not to feel over-confident (and I'd be worried if they were) since it's not something they should feel familiar with configuring on a daily basis, unlike say the compiler.
| Quote: | | Quote: | | just don't get suckered into believing that policykit is needed. |
I hope that my remark could not be understood this way: I dislike policykit much more than systemd because of its security threat. |
Heh no, was aimed more at the general topic: by all means disable it, but if you think policykit is some sort of design "answer", then imo YDIW.
| Quote: | | In fact, I do not see much relation between policykit and pam at all: Policykit is mainly about giving access to all /dev/... files if it is used instead of accessing the files directly. This is completely orthogonal to what pam does and is more about ignoring the permissions of the unix file system than anything else. |
Well the latter makes me want to vomit, and the actual use-case is what udev was supposed to fulfil, at least from what I read on kernel list.
And that's my concern with the systemdbug-nubkit-chensink fiasco: what starts out as one simple thing, doing its job, turns into a nightmare of complex interdependencies, kludged together in one "project" and called "modular" because there's so many parts to the swiss army-knife.
And as any carpenter or plumber can tell you, a swiss army-knife is more of a toy than anything else, when it comes to actually getting results beyond opening the odd tin.
| Quote: | | My concern about anytihing running with root privileges is not so much a mistake in the configuration (although also this is much simpler to mess up with policykit than with pam), but more about bugs in the code itself: race conditions, array overflows, pointers to free memory, ... simply each line of code is a potential thread: The code running with root privileges should be kept as small as possible. |
Yes, ofc: follow that through, in combination with the need for admins to be able to override, or setup authentication against one of N possible database types, and you get to pam: the pam module author has the task of worrying about that, so we (programmers and admins both) don't have to. The admin ofc has to know what they're doing, and the coder to use the API, but really it's setup so we have the least to do of all, which is exactly how a lib should work.
Look ma, no crappy localised leech-RPC! ;-)
Glad we both agree that policykit is a worse idea, at least. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Sep 22, 2014 6:40 am Post subject: |
|
|
| charles17 wrote: | A clear recommendation like "If you dont't know if you need it you don't need it" should go into a new section "Who needs it, what is good for?" on https://wiki.gentoo.org/wiki/PAM
Most 'home users' like me are only getting confused by such brilliant admin tools. |
That would be our recommendation, then: turn it off pre-install, and use sudo instead. Turn off ldap too.
Though if you want "brilliant" admin tools, systemdbug is there for you: many hours of frustration await, and in a few years you can look back with satisfaction, same as all the masochists who finally made Pulsefail half-work after 5 years of immense effort. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Sep 22, 2014 10:44 am Post subject: |
|
|
| steveL wrote: | | you keep banging on about home use |
This is what the original question is about. (Also, it is my only use case.  )
| Quote: | | Dunno I use mutt |
Actually, I use (al)pine, but I am not so only user on the machines; others need a GUI.
| Quote: | | it doesn't do Maildir properly |
I am always confused about the names for the format. (al)pine uses (by default, but maybe this is even the only option) the inode-saving solution of one file per mail-folder. This is also what kmail-3 and claws-mail support. But maybe "Maildir" means another format.
| Quote: | | Checking eix -e claws-mail doesn't show pam USE flag here |
Yeah, one should know how to use eix  My command was missing an "-e", so claws-mail (and perhaps other mail packages as well) appeared as a false positive in my list, because of the spamassassin useflag 
| Quote: | | and the actual use-case is what udev was supposed to fulfil |
I think, originally the use-case is related with logind: The logged-in user should be able to use sound/video/USB-stick/... without changing permissions of the devices. However, the latter restriction is completely arbitrary and superfluous, and so policykit actually has no use case, and it never had any.
| Quote: | | in combination with the need for admins to be able to override, or setup authentication against one of N possible database types, and you get to pam |
As I said: pam has its use cases. If you need it, there is nothing wrong to use it. The question is whether you do have such a use case: If you administer machines professionally, you probably do have; as a home user, you probably don't have.
| Quote: | | Glad we both agree that policykit is a worse idea, at least. |
I can hardly imagine that any sane person could see this differently. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Sep 22, 2014 4:43 pm Post subject: |
|
|
| mv wrote: | | This is what the original question is about. (Also, it is my only use case. ;) ) |
Heh, fair enough, though istr reading something about using policykit so we don't have to rely on pam, which strikes me as rank idiocy. The whole thing does.
| Quote: | | Quote: | | it doesn't do Maildir properly |
I am always confused about the names for the format. (al)pine uses (by default, but maybe this is even the only option) the inode-saving solution of one file per mail-folder. This is also what kmail-3 and claws-mail support. But maybe "Maildir" means another format. |
Yeah, it does, that sounds like mbox, which is not as robust under multi-client usage, or more cogently when transfer and reading are decoupled. I've always used Maildir, pretty much since I started using KMail. The only wrinkle in conversion, which the post covers first, was the hidden folders KMail uses for subfolders. It's easy enough to split out, and once you do you can use any Maildir client, though for some reason the other GUI ones which do support it, only do so in a limited or bastardised (Thunderbird) format, that is close to useless afaic.
Still, mutt rocks. I used to use pine too, many years ago, so I find it perfectly simple, and it's so lightweight, and resilient. I love that I can have 3 or 4 instances running, when I need to, and just logout without worrying.
| Quote: | | Yeah, one should know how to use eix :oops: My command was missing an "-e", so claws-mail (and perhaps other mail packages as well) appeared as a false positive in my list, because of the spamassassin useflag :lol: |
Lul; I had to look up the help for update the other day, when Griz referred to using -P; for the life of me I couldn't recall what it did, even though I chose and implemented the flag (it's short for: @preserved-rebuild, which is probably why I didn't remember it; it normally picks up on those itself from portage messages, and indeed the short-form was broken for a while with no-one noticing.)
| Quote: | | Quote: | | and the actual use-case is what udev was supposed to fulfil |
I think, originally the use-case is related with logind: The logged-in user should be able to use sound/video/USB-stick/... without changing permissions of the devices. |
Hmm more the other way round: the use-case has been used to justify two other projects that are completely useless, when the functionality was required (and known about) from the beginning: it was the main point of a userspace device manager, along with non-kernel firmware and "any other" userland setup (in classic kernel coder style.) OFC the tail-end is now wagging the dog.
Much like the "multiseat" use-case was hyped so extensively about consolekit the first time around, and is still used as justification for logind, yet network admins could never make it work securely, and after years of trying simply concluded it could not be made to work, and the whole thing was a dead-end.
| Quote: | | However, the latter restriction is completely arbitrary and superfluous, and so policykit actually has no use case, and it never had any. |
Yeah originally they were changing permissions, which left the device owned by the user when they logged out. What I find so extraordinary is the stubborn refusal to do any proper integration work at the DM/DE level, instead insisting on calling out to leech-IPC for everything, and writing libs that don't provide an API, unless you use that same leech-IPC whose only "appeal" for "enterprises" is to get round the GPL. Technically-speaking, it's a totally crap idea.
From where I'm sitting it's a crying-shame that so many people waste their time making broken designs work; but you can't argue with them, as I learnt from Pulsefail. And it is their time, so good luck to em. So long as they stay off my lawn ;-) |
|
| 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
|
|
Other Things Gentoo
