On Wed, May 08, Alexandr Malusek wrote:

"Guy Van Sanden" writes:

...

But there's a quickly increasing number of Linux machines. And the idea has been raised to bring them in to the NIS domain (as users on each station should be able to see which other users own certain data in clearcase). The problem is that every Linux-user has root on his/her own station. So bringing them into NIS makes it easy for them to 'su' to any desired user, and perform actions as that user.

Can this in some way be blocked?

IMHO, it can't. Actually, this was one of the reasons why NIS+ was developed.

That is not correct. NIS+ can also not prevent root from doing an "su - <user>". You can never prevent root from doing this. The only question is, how many damange he can do. To prevent root from a client to read the data of this user, you need something like secureNFS. You cannot solve this with NIS, NIS+ or LDAP. root can always disable this service and create the account local. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B

Yes. Under Yast2, the routing module is undet Networking/Advanced. On 8 May 2002 at 15:02, Mailing Lists wrote:

Dear sirs; i haven't had the chance to see if somebody answered me; i already asked for help... unfortunately, my mail client is Outlook... Well, right now I would like to know if there is a way to configure via yast 2 the routing tables of a 7.3 PE SuSE Linux.

If not, what should i do???

-- Jerry Feldman Portfolio Partner Engineering 508-467-4315 http://www.testdrive.compaq.com/linux/ Hewlett-Packard Company 200 Forest Street MRO1-3/F1 Marlboro, Ma. 01752

Thorsten Kukuk writes:

...

IMHO, it can't. Actually, this was one of the reasons why NIS+ was developed.

That is not correct. NIS+ can also not prevent root from doing an "su - <user>".

Well, I've shortened my ideas too much and it led to confusion. I'm sorry. The reason why it cannot be implemented is that no stable SecureNFS implementation is available for Linux. The only reference I've found is http://www.cs.vu.nl/~gerco/SecureRPC/. (I wish I'm wrong here.) The note about NIS+ is not quite appropriate in this context because SecureNFS can be used with NIS too. I wanted to say that the distribution of public keys (which are needed by SecureNFS in Sun's implementation) is handled by NIS+ "automatically". In NIS, the maps must be created and some other changes must be made by the administrator in order to get SecureNFS working.

You cannot solve this with NIS, NIS+ or LDAP.

I fully agree. But the question is what options we have on Linux? I was thinking about AFS or Arla as distributed file systems and Kerberos. -- Alexandr.Malusek@imv.liu.se