Roaming User Profiles

[Dylan]

On Thursday 20 June 2002 03:54, Neal Lippman wrote:
> 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.

I have thought of doing this for icon size and font metrics due to massively 
different screen resolutions, but the settings are scattered through many 
files. Maybe the devel team could think about organising the setting in 
config files according to function rather than app. The app can always have a 
config file which over-rides the default.

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

Surely, when it comes to it, a physical intruder is at least partly beyond the 
scope of real-world (i.e. practical and useable) software security. If you 
try to make your system too secure, it becomes either 

A) unusably slow/inconvenient etc;
B) unmaintainable thru complexity;
C) unstable thru software interraction; or
D) all of the above and more.

In reality, the only stuff which MUST be available in /home/joebloggs is 
config stuff. Other stuff (user data, and probably email settings, passwords 
etc.) can be sub-directoried in a cryptfs which is either mounted (requiring 
password) automatically in a login script, or manually. So your erstwhile 
intruder can fsck your beautiful desktop theme, but can't get at your data 
without much more effort. And if he's that determined to get in, he'll 
overcome whatever you try to do to stop him.

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

What's the problem with exporting /home/whoever for x users? I can't see why 
that would lead to any significant extra overhead - after all, you don't need 
an instance of nfsserverd for each export. I export the individual home 
directories (admittedly only 4) which allows me to restrict which users can 
log in at which station without mussing with password files. Also, it makes 
the automount easier because I simply hand /home over to autofs on each box. 
No symlinks, no odd effects on apps which don't cope with them properly, 
etc... AND, the user can only see their own directory. They have to know that 
they can cd to another one even tho it's not visible, etc...

Oh I ramble on (blame the vino)

>
> 3. KDE is not designed to handle multiple simultaneous logins, 

Why should you need to? If someone needs logged in on 2 machines, create 2 
users with appropriate permissions over each other.

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.

I hope not! Surely the first invoked instance locks the relevant file. If it 
doesn't, I'd want to ask why!

 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.

IMAP crawls to mind!!

Dylan

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

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