Roaming User Profiles

[Dylan]

On Friday 21 June 2002 00:10, Neal Lippman wrote:
> > > 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.

I didn't mean to suggest that 'security by obscurity' was a valid aproach, but 
in the context of a home LAN like mine it's sufficient because I know that 
the other users don't know a shell script from a dll. That's why my 
/etc/export looks in part like this:

/home/dylan 192....2/32 rw,no_all_squash
/home/dylan 192...0/24 ro,all_squash

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

It seemed to me that the original query implied someone wanted or needed to 
log in to two workstations regularly. If you need to show someone a file, or 
refer to it then the group or other permissions in rw(x)r--r-- would let you 
read the file from someone elses login. If it's a case of email collection - 
get off your lazy butt and go to you desk. Better still, don't leave your 
machine logged in with a screensaver!

I suggested 2 logins to overcome the problem, not as a general rule

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

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