boot messages

boot messages

[Justin Smith]

Part of my dmesg:

....................
usb-uhci.c: v1.268:USB Universal Host Controller Interface driver

avc:  denied  { search } for  pid=93 exe=/bin/cat dev=00:08 ino=1
   scontext=system_u:system_r:initrc_t
   tcontext=system_u:object_r:unlabeled_t
   tclass=dir

avc:  denied  { read } for  pid=93 exe=/bin/cat path=/devices dev=00:08
ino=2
   scontext=system_u:system_r:initrc_t
   tcontext=system_u:object_r:unlabeled_t
   tclass=file

avc:  denied  { getattr } for  pid=93 exe=/bin/cat path=/devices
dev=00:08 ino=2
   scontext=system_u:system_r:initrc_t
   tcontext=system_u:object_r:unlabeled_t
   tclass=file

avc:  denied  { mounton } for  pid=149 exe=/bin/mount path=/local
dev=03:0a ino=
32705
   scontext=system_u:system_r:mount_t
   tcontext=system_u:object_r:usr_t
   tclass=dir

avc:  denied  { write } for  pid=224 exe=/bin/mv path=/log dev=03:05
ino=96193
   scontext=system_u:system_r:initrc_t
   tcontext=system_u:object_r:var_log_t
   tclass=dir

avc:  denied  { remove_name } for  pid=224 exe=/bin/mv path=/log/ksyms.5
dev=03:
05 ino=96389
   scontext=system_u:system_r:initrc_t
   tcontext=system_u:object_r:var_log_t
   tclass=dir

avc:  denied  { rename } for  pid=224 exe=/bin/mv path=/log/ksyms.5
dev=03:05 in
o=96389
   scontext=system_u:system_r:initrc_t
   tcontext=system_u:object_r:var_log_t
   tclass=file

avc:  denied  { add_name } for  pid=224 exe=/bin/mv path=/log/ksyms.6
dev=03:05 
ino=96370
   scontext=system_u:system_r:initrc_t
   tcontext=system_u:object_r:var_log_t
   tclass=dir


It looks as though the system doesn't allow basic maintenance of the
logs...

I'll try changing the policy slightly (in initrc.te)

# allow initrc_t var_log_t:file rw_file_perms;
allow initrc_t var_log_t:file 
       { write read rename remove_name add_name unlink create search };

-- 


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: boot messages

[Stephen Smalley]

On 1 Dec 2001, Justin Smith wrote:

> avc:  denied  { search } for  pid=93 exe=/bin/cat dev=00:08 ino=1
>    scontext=system_u:system_r:initrc_t
>    tcontext=system_u:object_r:unlabeled_t
>    tclass=dir

I provided a possible explanation for these messages in my earlier
reply - see http://marc.theaimsgroup.com/?l=selinux&m=100688827827241&w=2.

> avc:  denied  { mounton } for  pid=149 exe=/bin/mount path=/local
> dev=03:0a ino=
> 32705
>    scontext=system_u:system_r:mount_t
>    tcontext=system_u:object_r:usr_t
>    tclass=dir

I'll add this permission to the example policy.

> avc:  denied  { write } for  pid=224 exe=/bin/mv path=/log dev=03:05
> ino=96193
>    scontext=system_u:system_r:initrc_t
>    tcontext=system_u:object_r:var_log_t
>    tclass=dir
<text deleted>

I've seen these messages on RH7.2, and am adding permissions for RH7.2,
but I've never seen them on RH7.1.  RH7.1 is still our recommended base
platform, although we are working on the transition to RH7.2, as I've
explained in other postings.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

boot messages

[Andries.Brouwer]

Comparing my net sources with the vanilla sources showed
a series of differences of which I sent most to you
a moment ago. We still have one point of discussion.

>> I suppose these can be removed altogether.
>> For now #if 0 ... #endif.

> would it not be preferable to mark these as KERN_DEBUG instead?

I don't think so, but am willing to be convinced by Alan
in the case of lba48 messages. In the other cases these
messages just have to go.

Boot messages must tell us what hardware is detected.
We must not have debugging messages stating how
much memory is allocated for slab cache or so.
One can ask /proc after booting, and unless there are
serious bugs in the code such things do not affect booting.

When disk hardware is detected, I want to see manufacturer,
model, serial number and capacity.
When ethernet hardware is detected, I want to see manufacturer,
model and MAC address. (Possibly also IRQ and ioport.)

You never reacted, so I keep saying this until you either
take this patch or explain why in case of this particular driver
it is a bad idea to reveal the MAC address in the boot messages.

[I have also more general patches making sure that the MAC address
is printed in a uniform way by all drivers, but that comes later.]

Some more or less unrelated stuff below the patch.

Andries

diff -u --recursive --new-file -X /linux/dontdiff a/drivers/net/3c59x.c b/drivers/net/3c59x.c
--- a/drivers/net/3c59x.c	Sun Apr 20 12:59:32 2003
+++ b/drivers/net/3c59x.c	Sun Apr 20 19:07:00 2003
@@ -1456,15 +1456,20 @@
  		acpi_set_WOL(dev);
 	}
 	retval = register_netdev(dev);
-	if (retval == 0)
+	if (retval == 0) {
+		int i;
+		printk("%s: 3c59x, address", dev->name);
+		for (i = 0; i < 6; i++)
+			printk("%c%2.2x", i ? ':' : ' ', dev->dev_addr[i]);
+		printk("\n");
 		return 0;
+	}
 
 free_ring:
 	pci_free_consistent(pdev,
-						sizeof(struct boom_rx_desc) * RX_RING_SIZE
-							+ sizeof(struct boom_tx_desc) * TX_RING_SIZE,
-						vp->rx_ring,
-						vp->rx_ring_dma);
+			    sizeof(struct boom_rx_desc) * RX_RING_SIZE
+			    + sizeof(struct boom_tx_desc) * TX_RING_SIZE,
+			    vp->rx_ring, vp->rx_ring_dma);
 free_region:
 	if (vp->must_free_region)
 		release_region(ioaddr, vci->io_size);


A separate discussion:
Ethernet cards are numbered differently by different kernels.
A bit annoying, and I have tried to fix this a few times,
but probably one just should accept it.
The previous time this came up people answered and said:
use "nameif". OK. So I do, and I explained some SuSE people
my setup - perhaps they will try to make it standard.
But things are really kludgy.
With built-in ethernet cards I cannot use nameif to reshuffle
numbers. The only thing that works is to use entirely fresh
numbers. So if different kernels detect eth0 .. eth3 in
different orders then I can have "nameif eth4 $ADDR0" etc
in a boot script, and use eth4 .. eth7.
I don't know whether this was intended, or should be regarded a bug.

Re: boot messages

[Jeff Garzik]

On Tue, Apr 22, 2003 at 02:45:51PM +0200, Andries.Brouwer@cwi.nl wrote:
> Comparing my net sources with the vanilla sources showed
> a series of differences of which I sent most to you
> a moment ago. We still have one point of discussion.
> 
> >> I suppose these can be removed altogether.
> >> For now #if 0 ... #endif.
> 
> > would it not be preferable to mark these as KERN_DEBUG instead?
> 
> I don't think so, but am willing to be convinced by Alan
> in the case of lba48 messages. In the other cases these
> messages just have to go.

FWIW, we don't like adding ifdefs to the kernel anyway.  Even if
you disagree WRT my KERN_DEBUG point, a tangent objection is also to
the #if's themselves.  I prefer a C if, or looking at the driver and
finding an appropriate existing #ifdef DEBUG construct.


> Boot messages must tell us what hardware is detected.
> We must not have debugging messages stating how
> much memory is allocated for slab cache or so.
> One can ask /proc after booting, and unless there are
> serious bugs in the code such things do not affect booting.
> 
> When disk hardware is detected, I want to see manufacturer,
> model, serial number and capacity.
> When ethernet hardware is detected, I want to see manufacturer,
> model and MAC address. (Possibly also IRQ and ioport.)

agreed

For ethernet: mmio/pio port, mac addr, irq.  Most PCI net drivers should
already do this, and patches to add missing information are welcome.


> You never reacted, so I keep saying this until you either
> take this patch or explain why in case of this particular driver
> it is a bad idea to reveal the MAC address in the boot messages.

well, you did the right thing, with resending :)


> [I have also more general patches making sure that the MAC address
> is printed in a uniform way by all drivers, but that comes later.]
> 
> Some more or less unrelated stuff below the patch.
> 
> Andries
> 
> diff -u --recursive --new-file -X /linux/dontdiff a/drivers/net/3c59x.c b/drivers/net/3c59x.c
> --- a/drivers/net/3c59x.c	Sun Apr 20 12:59:32 2003
> +++ b/drivers/net/3c59x.c	Sun Apr 20 19:07:00 2003

this looks ok to me.

In fact, I am wondering why this code wasn't here before, in fact,
because Donald Becker (original author) is usually pretty good about
printing out the MAC/etc. information for each interface found.


> A separate discussion:
> Ethernet cards are numbered differently by different kernels.
> A bit annoying, and I have tried to fix this a few times,
> but probably one just should accept it.
> The previous time this came up people answered and said:
> use "nameif".

Two points here:

1) official answer is, "if you want stable ethernet interface naming,
use nameif"

2) I have been told more than once that ethernet device allocation order
changed between 2.4 and 2.5.  I consider this a bug, and welcome patches
to fix it.  Note, though, that the recent PCI probe order fixes that
went in via Andrew Morton may have addressed this issue for some people.

	Jeff

Re: boot messages

[Randy.Dunlap]

On Tue, 22 Apr 2003 09:01:36 -0400 Jeff Garzik <jgarzik@pobox.com> wrote:

| > A separate discussion:
| > Ethernet cards are numbered differently by different kernels.
| > A bit annoying, and I have tried to fix this a few times,
| > but probably one just should accept it.
| > The previous time this came up people answered and said:
| > use "nameif".
| 
| Two points here:
| 
| 1) official answer is, "if you want stable ethernet interface naming,
| use nameif"

I did a short writeup about this.  See
  http://www.xenotime.net/linux/doc/network-interface-names.txt

| 2) I have been told more than once that ethernet device allocation order
| changed between 2.4 and 2.5.  I consider this a bug, and welcome patches
| to fix it.  Note, though, that the recent PCI probe order fixes that
| went in via Andrew Morton may have addressed this issue for some people.

Patch has already been posted 2 times.

--
~Randy

Re: boot messages

[Jeff Garzik]

On Tue, Apr 22, 2003 at 07:20:23AM -0700, Randy.Dunlap wrote:
> | changed between 2.4 and 2.5.  I consider this a bug, and welcome patches
> | to fix it.  Note, though, that the recent PCI probe order fixes that
> | went in via Andrew Morton may have addressed this issue for some people.
> 
> Patch has already been posted 2 times.

Out of sight, out of mind.  :)

I am also wondering how link order and PCI detection order are affecting
things, so re-testing without patches on 2.5.68-bk3 would be useful, for
those having problems.

Re-send the patch against 2.5.68-bk3 if the problem persists...

	Jeff

Re: boot messages

[Andries.Brouwer]

> I did a short writeup about this.

Thanks!
Andries