[SATLUG] Why have Linux permissions become so complicated?

Don Davis dondavis at reglue.org
Tue Aug 4 14:30:43 CDT 2015

I've been having to work more with PAM recently (for LDAP...) and
appreciate the modularity and configurability.
Aside of that- the inseparable, interwoveness has crept in making more
and more problems.

Recently, I've experienced some unrecoverable (&undiagnosable to me)
errors with systemd. Things that wouldn't have (so trivially) broke
years ago - stop the system now.

Oddly enough, right before I read this message, I was asking myself if
Slackware was systemd less and if I could go back to basics with it....

On 08/04/2015 01:09 PM, steve kolars wrote:
> Agreed. The idea behind Unix/Linux is supposed to be simplicity. Besides
> the points Bruce brought out, lets step back and look at it from the
> security point of view (as weird as that sounds). The more complex the
> system the more prone it is to error. Too many daemons running equal too
> many points of attack, too many points to defend (it is not a one-for-one
> relationship).
> If I do not need it, I should not have to run it. This tying stuff together
> has crept and crept in Linux until it has become a real problem (problem is
> the nicest word I can think of). The best example I can think of is
> "systemd." ¡¡¡What a Trojan Horse!!! It has become such a "problem child"
> that I have gone to BSD for most work. For Linux I am really looking at
> going back to Slackware, where we all started.
> On Tue, Aug 4, 2015 at 11:57 AM, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
>> I've been looking at some permissions issues lately.  It strikes me that
>> the Linux system has become much more complicated over the years.  There
>> are a couple of issues.
>> First there is Linux-PAM.  This has been around for a long time.  I often
>> wonder why it is needed.  I used to try to ignore it, but there are just
>> too many applications that seem to require it for that.  I do know that it
>> can be useful in a multi-user environment using ldap for logon credentials,
>> but how common is that?
>> Second is polkit.  This is something that is only useful in a graphical
>> environment with multiple users.  What is it's purpose on a laptop?  On a
>> server without Xorg?  Again, there are many apps that seem to demand it.
>> Third is ConsolKit. ConsoleKit is not being actively maintained.  They now
>> say to use systemd-logind.
>> http://www.freedesktop.org/wiki/Software/ConsoleKit/
>> To make things worse, to implement this complexity, applications like
>> upowerd, polkitd, console-kit-daemon, etc are run as daemons even after a
>> graphical session is terminated.
>> -------
>> To me, all these permission applications are only needed in an environment
>> where there are multiple users on a system.  In addition, if there are
>> multiple users, they need to be using a graphical desktop.
>> How many Linux systems in use fall into this category?  I really don't
>> know but I suspect it is a low percentage.
>> The whole idea about ConsoleKit, PolKit, and systemd-logind seem to
>> revolve around the idea of 'seats' and 'sessions'.  All the complication
>> seems to have evolved for systems that have seats > 1 or sessions > 1.
>> My question is: how often does this situation arise?  In the early 90's,
>> it was common to have thin graphical clients that connected to an
>> expensive, relatively powerful, central system.  That seems obsolete today
>> in the era of sub-$100 terrabyte hard drives and cheap multi-core
>> processors.
>> Is all this complication just because the upstream base distros, notably
>> RedHat and Debian and SuSE have a one size fits all approach to creating
>> distributions? Does everyone really have to have ALL the complexity needed
>> only by the very few?
>> My viewpoint may be limited.  What am I missing?
>>   -- Bruce
>> --
>> _______________________________________________
>> SATLUG mailing list
>> SATLUG at satlug.org
>> http://alamo.satlug.org/mailman/listinfo/satlug to manage/unsubscribe
>> Powered by Rackspace (www.rackspace.com)

More information about the SATLUG mailing list