>>> It's not that easy. You can have ext2 filesystems on ROM
>>> devices...
>> Only if the ROMfs is selected, whether "M" or "Y" is irrelevant...
> No. ROMfs is just a FS optimized for read-only and for requiring
> few space. You can put ext2fs on a ROM device, of course.
OK, wrong file system name, sorry...
>>> ...or a network block device.
>> You sure of that? I understood that NFS didnae use any of the other
>> file systems as it's a file system in its own right...
> No! You can put ANY filesystem on ANY block device. Why would
> somebody create nbd, otherwise? Read Documentation/nbd.txt, if you
> don't believe me. (It also says, that you need some program to set
> it up, so you can't use it as root device. But hey, use NFS as root
> and a nbd for your ext2 fs.)
>>> And it should be possible to compile a kernel w/o IDE and SCSI,
>>> but with ext2fs and nbd.
>> Possible, yes - but then, it's possible to compile a kernel
>> without support for a.out or ELF - whether such is sensible is
>> another question...
> I guess, you're right here. But have a close look at the other
> possible binfmts. binfmt_script is out of question as the
> interpreter has to be loaded ...
I only have 2.0.35 to hand at the moment, which allows just three
different formats:
1. a.out
2. ELF
3. JAVA
The last needs to load the JAVA interpreter to be used, so inherently
needs one of the first two. As a result, if both of the first two are
selected "n" the system is severely crippled AFAICS...
> Maybe you can use a kernel for routing and forwarding network
> packets and things like that without needing userspace tools. But,
> yes, this is very unlikely.
Memory says that one needs userspace tools to configure those two
facilities in the first place - besides, to do anything, one needs to
log into the system, and /bin/login is an external program...
>>> If you want to put a warning for this case, OK, go ahead.
>> That's all I was referring to anyway...
>>> ... and the needed modules can still be added and inserted.
>> Even if the relevant options were selected "N" when configuring
>> the kernel? That's not my understanding.
> I have to admit, that I don't know how this is handled exactly. I
> know, it's possible to compile drivers for SCSI adapters as modules
> and inserting them after having compiled a kernel with "N"
> configuration for this adapter. Some modules might change the rest
> of the kernel by being selected with "M", but I think, Linus would
> not like such dependencies, and so there most probably only a few
> or none misbehaving like that.
I've never used SCSI since I don't have access to any systems using
it. However, my experience with the things I have tried indicates that
the following rules are true:
1. If CONFIG_MODULES="n" then nothing can be loaded as a module,
irrespective of anything else.
2. If CONFIG_FAT_FS="n" then none of the DOS FAT based file systems
can be loaded, even if modules for them are available.
3. If CONFIG_NFS_FS="n" then any attempt to load or use NFS results
in a syslog message stating that the kernel does not support NFS.
I have a feeling that the SCSI system is an exception to this pattern
since I have also heard of people being able to mount SCSI modules
that were selected "n" when the kernel was compiled, but as stated
above, I have no direct experience of this.
>>> The modules add significant complexity to your sanity checks.
>> Why?
>> IMHO all the sanity check needs to deal with is whether or not
>> options are set as "n" which in each case is a Yes/No decision. As
>> an example, have a look at the following, which generates an error
>> if the a.out and ELF executable formats are both set "n" since the
>> resulting kernel is rather less than useless...
>> ===8<=== CUT ===>8===
>> --- linux/arch/i386/config.in~ Mon May 13 05:17:23 1996
>> +++ linux/arch/i386/config.in Thu Dec 3 22:14:45 1998
>> @@ -36,6 +36,12 @@
>> if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
>> tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA
>> fi
>> +if [ "$CONFIG_BINFMT_AOUT $CONFIG_BINFMT_ELF" = "n n" ]; then
>> + echo '*** ERROR: Either a.out or ELF format is' \
>> + 'ESSENTIAL for Linux to work.' >&2
>> + echo ' Aborting configuration.' >&2
>> + exit 1
>> +fi
>> bool 'Compile kernel as ELF - if your GCC is ELF-GCC' CONFIG_KERNEL_ELF
>>
>> choice 'Processor type' \
>> ===8<=== CUT ===>8===
>> Perhaps you could advise what's complicated about that...
> If you are sure, it's never useful to have a kernel without both
> ELF and A.OUT support, then it's the correct thing to do.
With the 2.0 series kernels as currently exist, it's highly unlikely
to be useful since without one of those two, no external programs can
be loaded.
Also, and here I'm speculating as I don't know the answer, but can an
ELF compiled kernel be loaded if ELF support is not included?
> But in most cases, I would not like to have an ERROR. You can
> display a WARNING, if you think the kernel configurator does
> something very stupid.
The problem there is that "make config" which has no means to go back
to reselect an earlier option as currently written. To handle this
situation elegantly requires a serious rethink there...
With "make menuconfig", it would be easy to have a "comment" appear if
an insane option combination was selected, but a better option would
be something along the lines of the warning message popped up by
"dep_tristate" when one selects "y" for an option that depends on an
option selected "m".
With "make xconfig", there is no easy way to pop up a warning,
although the ability to go back and change an earlier option obviously
already exists. In addition, choosing the "comment" option referred to
in "make menuconfig" above would result in the comment being
permanently displayed, thus making it meaningless...
> Consider the NFS/network example. Imagine root to have compiled
> modules for the network support. For some reason (s)he wants to
> have NFS in the kernel, but not recompile the network modules
> (maybe because (s)he has a 386). You should not forbid to do that.
Nor can I see reason to even warn about it - to my mind, that's a
perfectly valid configuration
> Un*x is used by a lot of people who know very well what they are
> doing. You can easily annoy these, by not allowing them to do what
> they like.
That's why I'd like to see this sort of functionality implemented as
warnings as well, but that's not possible without modifying the
configuration scripts first...
>>> There are so many ways to screw your system if you are root and
>>> don't think enough before you are doing something. Un*x is about
>>> saving the user from doing stupid things but not root.
>> Why not root? We already include some checks to prevent root from
>> doing stupid things - for example, the kernel refuses to compile
>> if the compiler used is too early a version - and I can see
>> nothing wrong with putting in checks for other insane choices for
>> precicely the same reason - to reduce the bug reports caused by
>> setting such insane choices in the first place.
> The security concept of any Un*x-like system is based on the
> assumption that we can trust root.
That does not automatically assume that root is the world's top
genius (who would automatically realise how insane some combinations
can be), only that root has been given both the authority and the
responsibility of maintaining the system, nothing more than that.
As an example of what I'm getting at, take the following hypothetical
scenario:
Q> Linux was installed on a group of systems that all NFS mount
Q> their root directories some months back by a previous system
Q> administrator who has since left the company. A new system
Q> administrator has recently been appointed to take over those
Q> duties.
Q> Although none of the systems have them installed, the systems
Q> were set up with support for the IOmega parallel port Zip
Q> drive since some of the users have those drives available and
Q> bring them along to download and transfer files for their home
Q> systems. Since in this situation, the driver works best when
Q> compiled as a module, that's how it's set up.
Q> The new sysadmin is browsing through the kernel configuration
Q> to see whether it can be reduced in size since memory is tight,
Q> and notices that the SCSI subsystem is compiled in, although
Q> none of the systems have SCSI drives fitted. He therefore
Q> deselects it and recompiles the kernel without support for
Q> it, then puts the recompiled kernel as the one to use. He does
Q> NOT delete the ppa.o module since he didn't notice it in the
Q> first place.
Q> Following this, he gets a lot of users complaining that their
Q> PARALLEL port zip drives get corrupted when used on the system.
Q> (Don't laugh, that can happen under those circumstances). Since
Q> these are parallel port drives, he does not associate this
Q> problem with his removing the SCSI system, so spends several
Q> frustrating weeks trying to determine just what's gone wrong.
The system administrator was CORRECTLY trusted, and acted in what
(s)he thought was the best interest of all concerned. However, the
actions taken were WRONG!
This is one change I would like to see done, but wouldnae know how to
start: If an option is deselected that results in other options being
disabled, and any of those options are currently selected, some sort
of message should be displayed pointing out the fact, rather than just
blindly deleting those options as at present...
> The system needs to be set up, maintained, etc. and for this you
> need to be able to do things which can hurt you.
True, but is that a reason for encouraging root to be stupid, as
currently happens?
> I see no easy way out of this unless the computer becomes really
> intelligent. Then the computer will use humans to accomplish what
> it thinks is good
That would be a nightmare...
> You can screw or crash your system by deleting /lib/ld-linux.so.*,
> catting random stuff to /dev/mem, overwriting swap partitions etc.
> You don't want the kernel to check all this!
Nope, but I for one would like to be informed if an action of mine has
ramifications that I would be highly likely to overlook, and I see
nothing wrong with that.
If I'm going to do any of the things you mention, I'm highly likely to
be well aware of the ramifications, so there's no reason to get the
kernel to check. Likewise if I was to do "rm -fr /" as root, I would
not expect to have a working system afterwards...
> If you read linux-kernel, you probably noticed, that a lot of times
> users post a "Linux bug" or "security hole", which can just be
> exploited by root. Nothing which can only be exploited by root is a
> bug. At most bad policy. (I don't want to say that the kernel
> should do no checks at all, if you are root ...)
Agreed...
> BTW, there are some discussions how to better assign capabilities
> to users and root. The easy approach "root is allowed to do
> anything, the user almost nothing" is sometimes too stupid. Cause
> sometimes users need to do things which they can not be allowed in
> a general way, there's a large number of suid/sgid binaries and
> every single one is a potential security hole. Reducing the number
> of suid binaries needed is a good approach.
Definately agreed...
Related to this, I'd like to be able to stick the kernel source in the
standard directories, but allow users to compile variants of it in
their own userspace without having to copy the entire tree over. At
the moment, that's not possible though...
> If it's obvious and easy, add the checks. There's nothing wrong
> with it, then. If it's compilcated and non-obvious: Don't even try
> to get it right. You only complicate things then and the
> probability you missed something is really high.
True...
>>> If there are easy and obviously correct sanity checks (when you
>>> do something which never makes sense), then add a warning or
>>> error message.
>> Precicely what I said in the email you appear to take such
>> exception to, so what's the problem with doing that?
> You really have to think twice before you forbid anything to
> anybody.
I'd prefer not to forbid anybody from doing anything, but the current
"make *config" options don't have any direct means of producing useful
warning messages, as per my earlier analysis.
> Another example: I happen to maintain a SCSI driver (tmscsim) for
> the DC390/AM53C974 controller. In the Configure.in it used to check
> whether the AM53C974 driver is enabled and didn't allow the DC390
> driver to be compiled in, then. Nonsense! There might be perfectly
> valid cases to compile both, even if they support the same chip.
> Just imagine machines with, say, 2 DC390s and another onboard
> AM53C974 adapter.
> * Old versions only supported the Tekram DC390s.
> * Recent versions of tmscsim can be told to only support DC390s.
> So you can drive different adapters with different drivers, even
> with the same chip...
Agreed - I could see nothing wrong with that anyway...
> The example mentioned was also wrong, IMHO. It does make sense to
> compile ext2fs w/o IDE nor SCSI (nor floppy) support!
>>> In the kernel configuration process, there aren't many such
>>> cases, which aren't already prevented, IMHO.
>> {Shrug} The above case thereof was discovered with less than five
>> minutes study of the options presented by "make menuconfig", so is
>> hardly hidden. If such an obvious case is so readily apparent,
>> then there must be MANY more subtle ones...
> There are some config options you are not allowed to select, if you
> don't select the one they are dependent on. Eg. PCI devices w/o PCI
> support. I think most obvious cases are covered by such a logic.
Many are, but not all of them.
>>> I don't think, Linus will accept anything apart from cases, where
>>> it's obvious, that this configuration won't be any good.
>> I wouldnae think as much of him as I do if he accepted anything more
>> than that anyway, so I can't say that worries me...
> Agreed.
> I think we had enough discussion about this. I think you are
> wanting to find cases where the configurator is obviously doing
> stupid things. Think twice and add warnings (or errors, if it would
> result in a non-functional kernel) and post them. I think these
> will be discussed ...
Like I said above, until such time as a facility is added to the
various config scripts, warnings just aren't possible, so anything
inserted would have to be errors. That's why I havenae posted anything
yet...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/