On Wed, 26 May 2010 13:58:41 -0700
Mike Heinz wrote:
> My preference for bug fixes is that they be applied so that they go into the
> upstream kernel - assuming they don't require EWG-only changes. But I need
> to understand the correlation between the two source trees - if you accept a
> bug fix
In general, we would like kernel code to be reviewed and accepted (or at least
queued for
acceptance) upstream first and then submitted to to the ewg for the next OFED
release.
There are sometimes exceptions where things go into OFED before being accepted
upstream but in general, we would like t
It's better to be statically linked. However all setuid programs present a
threat. The challenge as a security administrator is to assess and minimize the
threat. Smaller programs where you can inspect and understand the program are
more trustable than large complex programs.
Richard
- Rep
My preference for bug fixes is that they be applied so that they go into the
upstream kernel - assuming they don't require EWG-only changes. But I need to
understand the correlation between the two source trees - if you accept a bug
fix for the upstream kernel, will that end up in OFED as well,
> The subject says it all. If I have a patch that can be applied
> against either the current OFED git repository or against the
> upstream kernel - where do I post it?
What do you want to happen to the patch? If you want it applied to the
upstream kernel, then send it to me and linux-rdma. I
The subject says it all. If I have a patch that can be applied against either
the current OFED git repository or against the upstream kernel - where do I
post it?
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailma
This is a simple fix. Several of the snoop filters in
./drivers/infiniband/util/madeye.c don't switch the attribute id to host byte
order before checking it.
Signed-off-by: Michael Heinz
diff --git a/drivers/infiniband/util/madeye.c b/drivers/infiniband/util/madeye.c
index 0cda06c..2c650a3 10
To steer the conversation in a different direction. Perhaps there is a need to
have a second umad device file which allows only for "Get" operations? I know
this could be some work and I don't know if it could be completely done (I have
not thought through all the details). [*]
I know there i
On 05/27/2010 02:19 AM, Woodruff, Robert J wrote:
> Hal wrote,
>
>> sudo can be configured for specific commands to be allowed to specific users.
>
> Then perhaps that is a safer way to do it, but it would put more work
> on the system admin to set it up for people, but if setting the permissions
>
If the application is statically linked and trusted, then, is there no
security issue ?
-Original Message-
From: Informatix solutions [mailto:rich...@informatix-sol.com]
Sent: Wednesday, May 26, 2010 9:30 AM
To: Woodruff, Robert J; 'Hal Rosenstock'
Cc: 'EWG'
Subject: RE: [ewg] Allowing
Vlad,
I've updated libnes library:
http://www.openfabrics.org/downloads/nes/libnes-1.0.1-0.3.g8d69734.tar.gz
latest.txt has been updated with the new file name.
The new library has this commit:
commit 8d697346deeed723d69c284e597c0ebcb11dc602
Author: Mirek Walukiewicz
Date: Wed May 26 17:30
On Wed, May 26, 2010 at 12:29 PM, Informatix solutions
wrote:
> The issue is that it is entirely dependent on the security integrity of the
> application with the setuid bit set.
> If someone can insert code, or swap a dynamically linked library with their
> own alternative, it becomes possible to
The issue is that it is entirely dependent on the security integrity of the
application with the setuid bit set.
If someone can insert code, or swap a dynamically linked library with their
own alternative, it becomes possible to have your own code executed as root.
The system is then completely com
Hal wrote,
>sudo can be configured for specific commands to be allowed to specific users.
Then perhaps that is a safer way to do it, but it would put more work
on the system admin to set it up for people, but if setting the permissions
of the commands to setuid root opens up a security hole, we w
On Tue, May 25, 2010 at 7:21 PM, Woodruff, Robert J
wrote:
> Hal wrote,
>
>>If you really want any user to do this, is changing umad permissions
>>sufficient ? This is less of a security hole than setuid but does open
>>things up for malicious users.
>
>>-- Hal
>
> I wanted to avoid doing this as
This email was generated automatically, please do not reply
git_url: git://git.openfabrics.org/ofed_1_5/linux-2.6.git
git_branch: ofed_kernel_1_5
Common build parameters:
Passed:
Passed on i686 with linux-2.6.18
Passed on i686 with linux-2.6.19
Passed on i686 with linux-2.6.21.1
Passed on i686
Tung, Chien Tin wrote:
> Vlad,
>
> Please pull my git for this commit:
>
> RDMA/nes: fix incorrect unlock in nes_process_mac_intr
>
> at:
>
> git://sofa.openfabrics.org/~ctung/ofed-1.5.git ofed_kernel_1_5
>
> Thanks,
>
> Chien
>
> --
> Chien Tung | chien.tin.t...@intel.com
>
Done,
Regards
17 matches
Mail list logo
