Roaming User Profiles
nl at lippman.org
Thu Jun 20 03:54:29 BST 2002
On Wednesday 19 June 2002 15:31, Christian Müller wrote:
> Am Dienstag, 18. Juni 2002 22:33 schrieb Kevin Krammer:
> > On Tuesday, 18. June 2002 22:17, Dolson,Joan \[PYR\] wrote:
> > > Our users move to different Linux workstations frequently depending on
> > > which "desk" they are manning on a particular day. They would like to
> > > save their KDE desktop settings and retrieve them on whichever machine
> > > they are using for the day so that their applications automatically
> > > start up on the particular KDE desktop and position that they like. We
> > > are using Red Hat Linux 7.2 with KDE 2.2-10 and the applications they
> > > run are non-KDE apps. We have about 25 users who rotate between 8
> > > workstations and only one administrator so we would like to find a way
> > > to centralize saving and retrieving the desktop settings.
> > If the logon to machines on the same network, you can easily have the
> > home directories on a server and mount them vai NFS.
> > User specific settings of programs are always saved to the suers home
> > directory, so this is independend of KDE.
> But is there a way the secure this against concurrent accesses,
> e.g. if one user is logged into two workstations at once?
> Wouldn't there otherwise be a certain risk of data corruption?
I've been thinking about the issue of a centralized datastore and multiple
workstation logins too, but I'm not sure how that can be achieved properly.
I use the NFS mechanism on my home LAN. Each workstation mounts the exported
/home nfs share onto /nfs, and home directories are set up as symlinks, eg
/home/nl -> /nfs/nl. That works just fine (except for the occasional odd time
when the network hangs and the home directory becomes inaccessble).
Although I haven't actually done this, one could conceive of code in
.bash_profile or .bashrc that would determine characteristics of the
workstation itself (from environment variables or specific data stored on
each workstation) that could be used to configure the desktop based on which
workstation you are actually logged in to.
There are some big problems with this setup:
1. NFS shares are inherently insecure, because of the way that they to logon
validation. For instance, if I can become root on any workstation that has
the nfs share mounted, then I can then su to any user I want and access that
person's nfs share. Even if I don't have the ability to become root on any
workstation, if I wanted to hack someone elses files, I could do so quite
simply: log on to any workstation, find out its ip address. Then, disconnect
that workstation from the network jack, plug my laptop into that jack,
configure the laptop to have the same ip address as the workstation is it
replacing, become root, mount the nfs share....so the nfs technique works
fine on my home lan, where security is more to keep the kids from breaking
anything of mine than for real "security", but is a problem in production
2. I think you could get around the security issue with a script, run at
login time with root privileges which mounted ONLY the nfs share of the user
logging in, but to do so you need to export EVERY directory in /home on the
nfs share because you can only mount the mount points specifically described
in /etc/exports, and not selectively mount only part of the tree unless it
too is listed in exports.
3. KDE is not designed to handle multiple simultaneous logins, nor are any
KDE apps that I am familiar with. For instance, what happens if I have KMail
open on two different workstations accessing the same ~/Mail/* files? I
suspect there would wind up being data corruption, because there isn't any
way for the two instances of the program to cooperate. What would really be
needed here would be a backend mail database, that properly serializes
accesses, and a mechanism whereby a change made by one instance would somehow
be communicated to another.
This message is from the kde mailing list.
Account management: http://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde