Controlling changes to user settings

[Robin Rosenberg]

söndagen den 5 januari 2003 10.20 skrev Basil Fowler:
> A few extra comments.
>
> KDE should be installed system wide by root in either /usr/ or /opt
> directories ( distro dependent ) This provides a locked system.  But in
> addition, each user has a .kde directory in his/her /home directory.  This
> is under the user and that user only's control.  Such thing as backgrounds
> or font sizes can be set individually.

What you want to do when you have a large set of machines is to restrict things 
even further, such as what settings a user can change. Why? To stop them
fouling up and have to wait for help desk to fix their problems before they can
continue working. 

That a user cannot change system-wide settings is a basic requirement even in 
Windows  (>=NT) shops. No doubt you can change ownership and access to 
files in the user home directory, but does KDE work after that? How
much write-protecting files can KDE stand? Can users circumvent the restrictions?

> The user can do what he / she likes within the personal directory, but at
> the worst can only foul up his / her personal nest.  The key files will
> remain untouched.  This is one reason why Linux is virus resitant.

(The reason for commenting this thread).
It's not resistant, it is not targeted. A Linux virus is not likely to get a high penetration 
due to the heterogenous environment, so there is very little incentive to write one. There 
are some conceptual viruses made just to prove the concept. Some Linux users run as
root and are thus sitting ducks even for the classical boot sector viruses. If someone cared.

Worms and trojans are a little more fun, so there are a few. Note that the KLEZ virus/vorm, 
which  is windows program works if you have wine installed. It does not launch automatically,
but a dumb user may run the exe.

The worst mistake you can do regarding security is to believe that something is completely
secure that is not. I've seen big Unix environments where shell script were sent around and,
executed indiscriminately. That spells BIG hole, just that noone was running trucks through them,
so the benefits outweighed the risks. I'm not sure that any of the responsible persons considered
the risk, except those of us that made jokes about it. When I grew up peoply were leaving things
around everywhere without locking, simply because nobody stole anythng. The times are a'changing.

> You might also read up about the Red Hat User Private Group system, which
> simplifies the administration of sets of files where only a sub-group of
> users are allowed access.
>
> Remember that Linux is a Unix clone, and Unix was designed from ground up
> as a multi user system.  Such problems of access and control has been
> encounted and solved before Bill Gates had even bought his first Altair,
> and there was no such thing as a GUI.

Several things in Linux, like sound and joysticks aren't very multi-user friendly
in Linux even today. Security in early Unix systems was very weak. It was
mostly used to prevent users from making mistakes.

> Indeed many of the features of MS-DOS 2 were poached directly from UNIX!!

Borrowing good ideas is good (as long as you don't steal credit for them).

> Another point - Linux-KDE is rather like the MS-DOS 6 / Windows 3.1
> combination.  The GUI is NOT integrated with the OS ( Linux ).  As JRT
> says, control is applied at the OS level, so you should master the simple
> console commands.  In the case of trouble, it is a relief not to have to
> the additional rigidity and complexity of a GUI to consider.

Not end users configuring KDE. There is a big difference between super users who
can and want to control every aspect of their machines, and end users in
a corporate environment who only needs access to a small set of applications. Any 
extra applications and settings are just a burden.

[snip]
> Basil Fowler

-- robin


___________________________________________________
This message is from the kde mailing list.
Account management:  http://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.