Roaming User Profiles

[Neal Lippman]

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

	I don't agree, at least not fully. Exporting each user's /home is 
reasonable, provided there aren't too many - I'm not sure it would make sense 
to export 100's or 1000's of users - but if you are running a system with 
that many users and distributed logins, you might want to use something from 
MIT's Athena project, or AFS for home directories anyway.
	Having autofs handle the /home directory problem at login is certainly 
reasonable, but I disagree with a security system that relies on a user not 
knowing that (s)he can just CD to someone else's dir - security based on 
hiding information isn't robust. Remember also that nfs spoofing as I 
outlined is accessible only to someone who is root on a workstation, which 
implies (but doesn't guarantee!) some level of knowledge beyond that if a 
newbie user.
	Finally, while I agree that systems are always vulnerable to someone with 
physical access, since the cracker (in theory) doesn't have access to the 
file server, there should be (and are) solutions that enable security, but 
they are more complicated than a simple nfs share. Again, MIT's Athena 
project has done with fully kerberized end-user applications and servers.
>

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

	The idea is distributed logins. Each user should have ONE network wide 
login, not multiple logins depending on which workstation is being used or 
how many workstations are being used. Here's a scenario: you come to work in 
the AM, login in to your office workstation, then get up to do something 
outside your office. (Of course, you xlock your screen when you leave!). Now, 
you are in a common area or a colleagues office or whereever, when you need 
to do something that requires you to log in - check a mail message, read one 
of your files for some info, whatever. The idea is that you should be able to 
just log in and have full access to your desktop, data, mail, etc, - without 
having to be concerned that you are still logged in elsewhere. Of course, to 
do this requires that this kind of access be supported by KDE (or Gnome, or 
whatever) from the ground up - and that may not be part of the design profile 
for KDE.
>
> nor are any
>
>
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.