Roaming User Profiles

[Neal Lippman]

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

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.

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