Hi,

I have two dasd devices, one is RW and the other is RO. I want to give the user access to ROOT, but keep them from root systems files. I am thinking that to achieve this, I can re-mount the /root directory to the RW device. Is this the way to go? If so, I can anyone give me directions on how to do this?

Thanks so much!

David

Mounting a directory in another place isn't that difficult. From 'man mount': "Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
mount --bind olddir newdir
After this call the same contents is accessible in two places." The real problem is that once a user gains root privileges s/he can access everything. Could you explain what tasks this user should perform that requires root privs?

I'm not sure what you're trying to accomplish. The number and type of drives and in the file tree has little to do with the type have access you've granted to various users.

From your post it sounds like you've mounted one of your DASDs as a rw drive and the other as a ro drive, but that's not going to get you very far if you're concerned about security.

Generally speaking, the user "root" should have rw access to your entire file system. (The Linux kernel runs a "root," and the kernel need to be able to read and write to anything in the entire file system. So if you mount a DASD ro you may induce kernel aborts and system failures.)

Other users should be created with rw permission to their personal home directory, usually a sub-directory of /home, but you can create users with a home directory anyplace you want to locate it. (For example, if you set up a user's home directory on a flash drive, and that user had several different physical system they used, they could just plug the flash drive into any one of those systems and be up and running as soon as their home was mounted. [I don't recommend this awkward method. It's only an illustration.]) By default, users are not granted write permission to any sensitive files, and they cannot even list the file in /root and several other sensitive directories.

Bottom line: Having a ro DASD on your system is not much additional security, and complicates your system management. If you're concerned about system security, I'd suggest that you review the posts in the security sub-forum, and look at the suggested links in (some of) those posts for suggestion about securing your system. You might also want to install and activate the enhanced access control system, selinux, if you need to control access to specific types of files using file level attributes.

Thanks guys...

I'm not concerned about security, but more about sharing of systems root files. I want to eventually have DASD shared between multiple Linux machines. The RO DASD would contain systems root files (var/lib/rpm, /usr, etc) that are the same across all Linux machines. The only thing is, the customer wants to have root access. I believe under z/VM I can control what the Linux machine has access to, if the DASD is RO, it shouldn't matter if the user has root access or not.

This may be the wrong way of approaching it, but I was thinking of:

Install
Re-mount or bind-mount /root to a RW DASD

Why are you concerned about /root? That's just the home directory of the user named "root." Having root access gives your customer complete control of the (virtual?) system, so they can remount anything you've mounted as ro as rw if that's at all possible. (I presume that you're thinking of physically disabling write access to the "ro" DASD?)

If you're not concerned about security, what's the point in this exercise?

By the way, one of the design goals of the Multics system (from which UNIX and GNU/Linux are direct dependents) is that any user may substitute their own executable image for any default executable. The kernel will always use the first executable it finds in $PATH to satisfy a command execution request. So "protecting" the root file system (which is /, not /root if you've followed the standard naming conventions) will not protect your users from messing up their own system.

As I suggested in my last post, implementing the file attribute controls of selinux might be a better, and easier, way to achieve your goals, if I have understood what you're trying to accomplish.