[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Poor Man's XT doc (pre-releace)



>>That fits 99% of all cases, but I'd love to have some Pentiums as X servers
>>to an Alpha server!
>
>I can't see why this is a problem. Unless you do something like share
>/usr (my preference, I prefer to mount /usr as RO, as this means only
>one copy needs to be kepts, at the expense that I can only update
>packages from a given "master" computer, for me this is my NFS server),
>I don't see why it should matter if the architecture of the
>NFS server or xdm server is different.

It's impossible to install software on a different platform to which it is
going to be used on.

>If you use something like the debian package, diskless boot, and
>modify the linux kernel with mknbi-linux, then I believe that
>"IP: Kernel level auto-configuration" is optional (not tested),
>and I have never needed /dev/nfs. I think mknbi-linux adds a header
>that passes these parameters to the Linux kernel. It is also required
>to make the diskless boot system recognise the image.

I've used LILO on boot floppies before which doesn't necessarily require
/dev/nfs (depends on how you do it).  If you're booting from a floppy (you
don't have and don't want boor ROMs in your network cards) then making
/dev/nfs is the easiest way of doing it.

>>X terminals generally run in insecure places, we don't really want someone to
>>use a different kernel and take over the machine to create SUID programs on
>>the server.  We may be able to run the X terminal with it's root file system
>>set up to be "root_squash" and have all files running as non-root.  I haven't
>>tried this, but it should work (but may take a bit of hackery).  Also
>>SUID-root programs on the NFS-root would have to be made non-SUID (probably a
>>good idea anyway if you want to have only 2 processes running on the machine).
>
>I am confused... How do you intend to run X as non-root? I think it
>might be better just to make mount the NFS partitions as read-only,
>for normal use.

Normally you have an Xserver that's SUID root (or a SUID root wrapper for it)
so that regular users can run it and access the hardware (which currently
requires root access).  This is not desired on an Xterm as all processes run
as root user.
If you have the NFS server setup as root_squash then the client computer (the
X server) will have read access to all files (give them all world-read
access) but no write access apart from /tmp.  I believe that Stephen's latest
idea of exporting read-only and then using a RAM disk for /tmp is a better
idea though.
I wouldn't be inclined to skip the ext2 file system though.  I believe that
ideally an X terminal will use kmod and have a whole range of modules
including sound drivers and drivers for all floppy disks.  Basically IMHO you
want your X server to have drivers for every IO device you're likely to want
to connect to it.

>The real problem I see, security wise, is that /etc cannot be read-only
>as it contains files that must be writable (I think), like /etc/mtab. This
>is really annoying. It also means that the root filesystem cannot
>be shared. The root filesystem must contain /etc, /bin, /sbin, so I seperate
>copy of all these files must be kept.

AFAIK /etc does not need write access.  /etc/mtab is not written if you use
the -n option of mount (you can have a pre-made version that says that
everything's mounted).  This is a problem for umounting (there is no -n flag
for umount), but you don't REALLY need to umount an NFS partition -
especially a read-only one.

>Of course, it may be possible to remount /etc as another writable
>filesystem during boot, but this approach still makes me nervous (any
>changes made to /etc will come out as errors before /etc is re-mounted).

I've been thinking of this.  There are some files such as /etc/hostname which
need to be different.  I was thinking of having them be sym-links to files
under /tmp and then generate the files on /tmp at boot time.

>Otherwise, it might just be possible to mount the entire root filesystem
>as read-only except for /tmp and /var. I have heard of schemes where
>the /tmp partition is a local harddisk that is formatted on start-up,
>removing any long-term security implications. A seperate copy
>of /var would be required for each diskless computer.

What do you need /var for?  No mail, no squid cache, no logs needed...

--
This is what they pay me for.


Reply to: