[rsbac] 2 problems with 1.3.7

[kang]

E. de Ruiter wrote:
> Hi,
>
> I just tried out the new enhanced kernel with rsbac 1.3.7 and it seems 
> that 2 problems that we had with the previous version (enhanced 2.6.21 
> kernel with rsbac 1.3.4) are still present (note: I never reported these 
> problems up until now because we didn't have time to report these 
> problems ..)
>
> 1)
> On our test-cluster we boot from network (nfs-root filesystem), but this 
> gives a problem with rsbac:
> we get tons of "rsbac_get_parent(): oops - d_parent == dentry_p!" on the 
> console rendering the system unusable.
> For that reason we comment out the rsbac_printk call in rsbac_get_parent 
> and then everything works fine (I have no idea was this message means 
> and if it could do any harm .. but the system is completely usable after 
> this edit).
>
> 2)
> On our production cluster we saw lots of kernel-oopses in originating 
> from the do_sock_read function. After some investigation it was clear 
> that most of the time postfix was triggering the oops. We ran some tests 
> on our test-cluster with smtp-source/smtp-sink (postfix benchmark tools) 
> and it turned out we could trigger the oops reliable when using 1 
> smtp-sink instance and 2 smtp-source instances each delivering 200 
> messages which are quite large.
> We also tested this without hyperthreading enabled on the machines 
> (effectively making it a non-smp kernel) without hyperthreading we 
> couldn't reproduce the problem. Also on a vanilla kernel this problem 
> doesnot occur.
> Futhermore we tried disabling the rsbac code in __sock_recvmsg (in 
> net/socket.c) (this function is inlined in do_sock_read) this fixes the 
> problem (running fine now for more than 3 months on our production 
> cluster) , but I don't know what rsbac functionality is lost ..
>
> Kind regards,
>
>   Eric de Ruiter
>   Amplixs Interaction Management
>
> _______________________________________________
> rsbac mailing list
> rsbac at rsbac.org
> http://www.rsbac.org/mailman/listinfo/rsbac
>   
Hi!

1)
About your issue #1 this is "normal" for some filesystem which do not
initialize properly, and the inheritance is broken. However this does
flood the syslog for every access (NFS access here) and we might need to
find a fix for that. Commenting it out is fine as a workaround as long
you know that inheritance will be broken. Feel free to open a bug or
wait for ao's  idea on the subject.


2)
I opened a ticket for your #2 issue on the bugtracker. See
http://bugtracker.rsbac.org/view.php?id=114

Please use the bugtracker if possible to track this issue. (If you do,
tell me the user and we will assign the ownership of this ticket to you)



Otherwise, here is a copy of the patch (against SVN, so update the
offset if not working for you):

--- net/socket.c        2008-02-20 13:30:15.000000000 +0100
+++ net/socket.c.new    2008-02-22 17:27:29.000000000 +0100
@@ -878,9 +878,6 @@ static inline int __sock_recvmsg(struct
                                    rsbac_attribute,
                                    rsbac_attribute_value))
               {
-                /* clear buffer */
-                if(err > 0)
-                  memset(msg->msg_iov->iov_base - err, 0, err);
                 return -EPERM;
               }
         #endif



Please tell us if this also fix the issue, and if not, send us a
complete copy of the oops message.

Thank you for your report!