Re: Reasons for rights policies, political or technical ? Was : Re: pm-hibernate as user
I will do what we call in French a "tir groupé"... I guess it might be
translated as grouped shots, but it does not sounds good to my ears...
See my recent post: Make sure your desktop environment is setting up
a
up proper consolekit session. Then stuff like that will work ootb.
E.g. if you are using KDE and GNOME you won't have to deal with that.
I'd say this is the price you pay for dealing with a more minimalist
DE
like LXDE.
Michael
I've read it.
I am not using any DE at all, simply an X server with a window manager.
It's enough for me.
I perfectly know that using such a light solution will gave me
problems, but, see, I am not able to understand why I have those
problems, which sounds more based on political reasons than technical
ones.
You speak about consolekit. Nice. Yet another software, to manage all
rights? Not nice.
In my computer, there are groups which are used to manage rights. I
think it could be possible to say "all users of group power can use
pm-hibernate". Why is it not?
Here is the real question I asked, because I do not want workaround, I
want things I am able to understand why I need to do, how they work (at
least the big picture), and how to do things differently, because
freedom only exists with choice.
Linux is designed to be a multi-user system. This means, that
system-access is strictly denied to normal users. It makes linux
safe.
You could easily configure sudo to do exactly what you want: Running
commands with elevated rights ... without root access for all
commands
and without a separate passoword. I have configured an own shutdown
script with sudo myself and use pmount for mounting devices as normal
user. And for administration (I also like to tinker with my system) I
simply use a "su" to become root -- why would that be difficult? On
Windows you first need to create a shortcut and then "Run as
administrator" and even then you are not able to e.g. delete
everything
you want.
But, where the ability to shutdown a system in your home is a security
hole? Same for asking a new IP, or changing the wifi network you want to
be connected to?
Yes, sudo can do what I want. Sudo is the same as su after all. But, as
su, it is a workaround for me.
You are speaking about mount, now, and I've forgot it, because I rarely
use it. Same here. For enterprises, it can be useful, but hey, mainly
for servers, and, not for most enterprise computers!
There are tools to check that softwares have correct behavior, and, at
least, you could let a user mount anything, if you just take care to
remove the media the right to execute things.
In fact, if we want maxi security, $HOME should be mounted without
execution rights. It is not, because it would be so boring...
That's exactly like the password thing for normal user. I could have
remove my user password, but I used a single space (yes, I know) because
it is needed if I want to do some tasks to have a valid password.
Thanks to this precaution, I have to install a software to make my
computer to log me automatically, which will use RAM for nothing,
because [XGK]DM stay in memory when you started your session.
Or I can simply set a single space as my password, and use a script to
say to bash that if it is run from TTY1 it have to run startx.
I did the second.
There is a solution for init, of course, but I do not know how to
manage to make an ssh connection between the two computers I have at
home (I know their mac address and their ssh public key). But I think on
that particular point, it is lack of knowledge from me.
True, but I rather have an overall-safe system and that
shutdown-issue
than an insecure system.
I do not see why shutdown is a security hole. For network, I can
understand, but shutdown? The boot procedure have to be secured, not the
shutdown one. Except for servers, which are the smaller part of
computers, with really specific needs, and professional people with
knowledge (at least, those pro should have... I have seen situation
where... well :) ) to manage them.
I think it is implied by the multi-user approach: If another user was
logged in at your computer (e.g. over ssh) and you just disabled
network
they would lose connection.
This point is interesting, and would explain also the shutdown issue: a
shutdown computer break connections ;)
But again, most computers are used with physical access, am I wrong? If
yes, I must be privileged to have 3 computers around me when I sleep ^^
Maybe a solution would be a physical group, for users which are using
computer from the physical keyboard. Of course, it is still possible to
have distant people on your computer in this situation, but you should
be aware of that anyway, for me, and in that case, competent enough to
understand what will happen to their connections.
Anyway, I do not think the polkit stuff manage that issue.
To keep professional systems secure, it's helpful to force users to
keep
their home desktop PC secure too, because security is a chain.
IMO it's ok to force users to take care about security.
Yes, security is a chain, you are right. And forcing users to care
about it is not a foolish fight. This is why I did not asked why /etc is
only accessible in write for root, in other things. In the other hand,
the default user is able to run scripts he installed on his own space,
which could send spam/virus and so break the chain.
Forcing the security would mean here that, by default, Debian should
mount $HOME with no-execute flag. And maybe /var too, but it seem there
are some scripts to run there, because trying that with the installer
resulted in failures :) (I tried several months ago)
I am complaining... well, more asking about reasons in fact, for stuff
for which I do not see security problem and which are only manageable
with root. Like network client control (dhcp-client, ifup, ifdown, which
I do not think impact on distant servers).
Maybe I should read source code of poweroff to understand how it's
done, maybe the reason is commented in source code.
I do not really know where dbus is needed on my computer:
my softwares usually do not need to communicate
That is a big problem.
Linux goes away from scripts and KISS for stable
systems and tends to become one big experimental blob.
I think that you can not force user to be responsible about security,
when you make configuration a hell where only specialized guys can find
their way.
From what I can see, now, when you ask how to use pm-hibernate with
normal user, people say to use something else, based on dbus, policykit
and upower. They propose to use a solution which needs 3 tools, 3
different tools to configure and to run, to do what should, or at least
could be a simple task!
That multiplication of tools to do a single task does not only have the
hard configuration issue and the stability issue you said (after the
quote, yes), they also add daemons, which run even when you do not need
them.
I do not like to add an indirection level to solve a solution.
I've fall in love with Debian because it's easy to tinker it. If it
have to change, I'll try to find another distro... but hopefully it will
come very late, or never.
Btw.to force users to take care about security is useless, when OTOH
things don't work any more, because something experimental is
considered
as stable. Debian is one of the few distros, that doesn't jump the
gun
on things, but other distros at least have a new release every half
year. For some applications it's useful to get new versions very
often,
but for the basics of the system it's insane.
I don't want to revive the systemd troll, but IMO, init scripts are
insane too, to understand them is really painful, they make you jump
from a file to another permanently (maybe there is a tool to create a
call diagram of them? It could make things really easier for beginners
as me). I do not know which one is the best.
Is not there is another solution, between them, a little higher than
init, but without systemd's weird dependencies?
I remember some article about Linus Torvalds complaining about the
over-security in distros, needing to use root account for most
actions.
Sometimes it's impossible to start some applications in a "normal
way"
as root. Sometimes even an editor only can be used with kdesu etc..
On some machines stuff as e.g. AppArmor is completely useless, it
only
will spam startup messages with information, that there are missing
rules, for your self-compiled things. But it differs between distros,
some distros set up tons of unneeded stuff, run tons of unneeded
services, for other distros you even have to install X manually.
What is AppArmor? I've read aptitude's description, but did not
understood it...
The problem is that upstream tries to force everybody to go the same
way. I cast an I on other *NIX and Debian does it too, there already
is
a Debian FreeDSP port.
2 Cents,
Ralf
You know, if you look in your installed packages on a debian, you will
also see weird things, depending on your usage: saned, colord, dbus,
cups, are some examples. You can remove some of them, but try to remove
cups, and you will have so many fun... Even installing libqtgui need
cups, wtf?
But I tried recently (2 months ago) to use backtrack, heavily based on
Ubuntu. It immediately made me remember why Ubuntu was not the distro
which made me switch to linux kernels: as windows, you can't remove
anything without destroying the whole system, so at the time I tried it
I stayed with windows: between two demons, the one you know is the
better :)
Debian is light enough for me currently, but I am looking after more
flexible stuff now that I've got the big picture of the system (kernel
excepted).
I know that gentoo could be the way to go for me, but honestly, I would
like to avoid it as best as I can, I'm a little feared by this monster
:D
Reply to: