-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Oct 28, 2001 at 07:24:29AM -0800, Ken Ambrose wrote: > I think you're looking for netgroups. Specifically, a list of which NFS > clients are allowed to mount (which?) NFS servers. It's not foolproof (IP > spoofing might be able to get you somewhere), and it's not secure (it's > still unencrypted), but it suddenly goes from "I brought my Linux notebook > in and did an 'rm -rf' on the development tree by accident." to being a > non-trivial endeavor. We used to do it at Cisco all the time -- and users
I wish. If the user has root access to the local system (which is easy to get if they're willing to re-install the system, as suggested by the OP), this is irrelevant, UNLESS you are willing to make every user's home directory its own NFS mount *AND* they will only be allowed to mount their stuff from certain specific hosts. In many environments, this is not possible, and in all environments it's tedious to maintain. This is especially true in an environment with a lot of users and/or a large turn-over rate. For example, we have a large lab, in which all engineers must be able to get at their home areas from whichever machine they are working on. We can not know what machine(s) that will be as it changes as often as several times a day, depending on what the engineer is doing. Managing this would be a full-time job for someone, not to mention a major hastle for the engineers... It's not tecnically impossible, it's just practically infeasable. Furthermore, there is usually a group of engineers working on the same machine at the same time. So more than one user's files will be available on the machine, in any case. They also need root access to the machines to do their jobs. This means that on any given machine, they can log in as root, and then execute the following commands (or whatever): # su - randomuser [randomuser@testhost ~ ]$ rm -rf . Bye bye files. Hello back-up tape. Assuming of course, that randomuser is one of the people who is working on the given machine. Now, IF you can limit specific users to logging in at specific hosts (or at least having access to NFS mounts from specific hosts), using netgroups can work fairly well. Unfortunately, it's not possible for some of us. It also makes it harder to log into a different machine if your personal workstation(s) (or network segment, etc) are on the fritz. It's only a good solution in a reletively small number of cases. One way to make this more viable is to prevent root access to the machines, if your local politics allow for such a policy. If you have mischeivous users, and you're worried about them re-installing the OS, then you also need to make some effort to lock down the machine physically (by removing removable-media drives, disabling them in the BIOS, and requiring a password to change BIOS settings). As I can tell you from personal experience (I've defeated some of these measures myself, in the past... ;-) these kinds of limitations will not deter a really determined user, but it may at least a) make it a lot harder, possibly detering them b) provide the opportunity for you or someone else who cares to notice what they're doing, and/or c) provide grounds for termination of their employment, depending on how seriously you and your company take such things. Personally, I like the idea of giving root access to engineers for one machine which they will be personally responsible for, and only providing NFS exports for that user on that machine. Full root access could be granted to any lab machines, but NFS mounts of user directories are not provided to those machines (you can still get your files via ssh/ftp/whatever from your own machine). And NO root access to any other machine. Engineers tend to find these limitations too cumbersome, and many environments do not allow for such policies. This would make netgroups a bit more viable a solution, though still somewhat tedious to maintain (but much better than my first scenario). - -- Derek Martin [EMAIL PROTECTED] - --------------------------------------------- I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE73CludjdlQoHP510RAjUcAJ4/jhDSrpcp/5mb8SBnG5xe2nd8jwCgkDSw aDIahwusWjE56Santxey58w= =iJjo -----END PGP SIGNATURE----- ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
