Controlling changes to user settings

Robin Rosenberg robin.rosenberg at dewire.com
Sun Jan 5 22:17:39 GMT 2003


söndagen den 5 januari 2003 18.52 skrev Lee W:
> On Sun, 2003-01-05 at 04:38, James Richard Tyrer wrote:
> <snip>
>
> > If the files and directories you want to control are owned by
>
> 'root:root', you can prevent the
>
> > user from writing to them.
> >
> > In a directory, no write permission means that the user account can
>
> NOT add or delete files.
>
> > If a configuration or: "*.desktop" file is root:root:644, the user can
>
> use the file but can NOT
>
> > modify it.
>
> I originally considered this idea however researching on my own box at
> home I found that even if a file is owned/group root.root in the users
> home directory if I gave the user read or execute access they were able
> to rename the file.

Not if the directories are owned by root and have the sticky 
bit (chmod +t) set. This is how /tmp is configured.

> As an example, consider I created a .kde directory with the users
> "mandatory" settings, there is nothing (as far as I can see) to
> prevent the user from renaming this to "kde.old" therefore when the user
> next logs in kde recreates the directory but with the users own
> permissions therefore they can change the settings at will.
>
> I also tried using symlinks but that has the same problem.
>
> As always with Linux I am sure there is a way around this problem I just
> cannot figure it out.

Hence the home directory must be owned by root, have the sticky bit set on $HOME
.kde and all other needed directories. The problem is the .kde and its subdirectories
are created when the KDE session starts, unless of course they are created already.

-- 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.




More information about the kde mailing list