Skip to contentSkip to conversation

root owned writeable files under /sys

DISCUSSION Applied Sumeet Lahorani 8 participants 19 messages Jun 3, 2010 – Nov 18, 2010 13 messages not in the archive InfiniBand

lore
Share & tools
lore
#0 lore raw

Hi All,

With ofed 1.5.1 (and it appears to be the case in prior versions as well), I see the following files created under /sys which are world writeable

# find /sys -type f -perm 222 -ls
 6834    0 --w--w--w-   1 root     root            0 Jun  3 14:50 
/sys/class/infiniband/mlx4_0/diag_counters/clear_diag
 8344    0 --w--w--w-   1 root     root         4096 Jun  3 14:43 
/sys/class/net/ib1/delete_child
 8343    0 --w--w--w-   1 root     root         4096 Jun  3 14:43 
/sys/class/net/ib1/create_child
 8295    0 --w--w--w-   1 root     root         4096 Jun  3 14:43 
/sys/class/net/ib0/delete_child
 8294    0 --w--w--w-   1 root     root            0 Jun  3 14:39 
/sys/class/net/ib0/create_child
 6017    0 --w--w--w-   1 root     root         4096 Jun  3 14:43 
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger

ib0 & ib1 are slave interfaces corresponding to the 2 ports on a ConnectX HCA.

At least the create_child & delete_child files appear to be dangerous to leave as world writeable because they result in resources allocations. I'm not sure about the others. Do these have to be world writeable?

- Sumeet

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
In reply to a message not in the archive
Quoted 5 lines · Sumeet Lahorani

I see the following files created under /sys which are world writeable /sys/class/net/ib0/delete_child /sys/class/net/ib0/create_child
At least the create_child & delete_child files appear to be dangerous to leave as world writeable because they result in resources allocations.

Yes, this looks bad. The below patch fixes that, I tested it on 2.6.35-rc1

[PATCH] make ipoib child entries non-world writable

Sumeet Lahorani <[email protected]> reported that the ipoib child entries are world writable, fix them to be root only writable

drivers/infiniband/ulp/ipoib/ipoib_main.c +2 -2
index df3eb8c..b4b2257 100644
@@ -1163,7 +1163,7 @@ static ssize_t create_child(struct device *dev,
 
 	return ret ? ret : count;
 }
-static DEVICE_ATTR(create_child, S_IWUGO, NULL, create_child);
+static DEVICE_ATTR(create_child, S_IWUSR, NULL, create_child);
 
 static ssize_t delete_child(struct device *dev,
 			    struct device_attribute *attr,
@@ -1183,7 +1183,7 @@ static ssize_t delete_child(struct device *dev,
 	return ret ? ret : count;
 
 }
-static DEVICE_ATTR(delete_child, S_IWUGO, NULL, delete_child);
+static DEVICE_ATTR(delete_child, S_IWUSR, NULL, delete_child);
 
 int ipoib_add_pkey_attr(struct net_device *dev)
 {

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw
In reply to a message not in the archive

Thanks. I realized that my earlier find command didn't capture all the files I was looking for. After your patch, the following still need to be addressed (all are mlx4 files)

# find /sys -type f -perm -222
/sys/class/infiniband/mlx4_0/diag_counters/clear_diag
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1

- Sumeet

Quoted 32 lines · Or Gerlitz
Quoted 6 lines · Sumeet Lahorani

I see the following files created under /sys which are world writeable /sys/class/net/ib0/delete_child /sys/class/net/ib0/create_child
At least the create_child & delete_child files appear to be dangerous to leave as world writeable because they result in resources allocations.

Yes, this looks bad. The below patch fixes that, I tested it on 2.6.35-rc1

[PATCH] make ipoib child entries non-world writable

Sumeet Lahorani <[email protected]> reported that the ipoib child entries are world writable, fix them to be root only writable

drivers/infiniband/ulp/ipoib/ipoib_main.c +1 -1
index df3eb8c..b4b2257 100644
@@ -1163,7 +1163,7 @@ static ssize_t create_child(struct device *dev,
 
 	return ret ? ret : count;
 }
-static DEVICE_ATTR(create_child, S_IWUGO, NULL, create_child);
+static DEVICE_ATTR(create_child, S_IWUSR, NULL, create_child);
 
 static ssize_t delete_child(struct device *dev,
 			    struct device_attribute *attr,

drivers/infiniband/ulp/ipoib/ipoib_main.c static ssize_t delete_child(struct device *dev, · line 1189

Quoted 8 lines
drivers/infiniband/ulp/ipoib/ipoib_main.c +1 -1
@@ -1183,7 +1183,7 @@ static ssize_t delete_child(struct device *dev,
 	return ret ? ret : count;
 
 }
-static DEVICE_ATTR(delete_child, S_IWUGO, NULL, delete_child);
+static DEVICE_ATTR(delete_child, S_IWUSR, NULL, delete_child);
 
 int ipoib_add_pkey_attr(struct net_device *dev)
 {

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#6 lore raw
In reply to a message not in the archive
Quoted 3 lines · Sumeet Lahorani

Thanks. I realized that my earlier find command didn't capture all the files I was looking for. After your patch, the following still need to be addressed (all are mlx4 files)

&& all are not part of the mainline kernel, as such, you should approach the ofed maintainers or make a comment when the relevant code is submitted upstream.

Or.

Quoted 4 lines

/sys/class/infiniband/mlx4_0/diag_counters/clear_diag /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#7 lore raw
In reply to a message not in the archive

I don't understand why mlx4_port1 and mlx4_port2 have world write permissions on your system. I can't see this from the sources nor from installing ofed-1.5.1 on my system. I agree though that the permissions for port_trigger and clear_diag should be changed. We'll push a fix to OFED 1.5.2.

Quoted 51 lines · Sumeet Lahorani

Thanks. I realized that my earlier find command didn't capture all the files I was looking for. After your patch, the following still need to be addressed (all are mlx4 files)

# find /sys -type f -perm -222
/sys/class/infiniband/mlx4_0/diag_counters/clear_diag
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1

- Sumeet

Quoted 37 lines · Or Gerlitz
Quoted 7 lines · Sumeet Lahorani

I see the following files created under /sys which are world writeable /sys/class/net/ib0/delete_child /sys/class/net/ib0/create_child
At least the create_child & delete_child files appear to be dangerous to leave as world writeable because they result in resources allocations.

Yes, this looks bad. The below patch fixes that, I tested it on 2.6.35-rc1

[PATCH] make ipoib child entries non-world writable

Sumeet Lahorani <[email protected]> reported that the ipoib child entries are world writable, fix them to be root only writable

drivers/infiniband/ulp/ipoib/ipoib_main.c +2 -2
index df3eb8c..b4b2257 100644
@@ -1163,7 +1163,7 @@ static ssize_t create_child(struct device *dev,
        return ret ? ret : count;
  }
-static DEVICE_ATTR(create_child, S_IWUGO, NULL, create_child);
+static DEVICE_ATTR(create_child, S_IWUSR, NULL, create_child);
  static ssize_t delete_child(struct device *dev,
                            struct device_attribute *attr,
@@ -1183,7 +1183,7 @@ static ssize_t delete_child(struct device *dev,
        return ret ? ret : count;
  }
-static DEVICE_ATTR(delete_child, S_IWUGO, NULL, delete_child);
+static DEVICE_ATTR(delete_child, S_IWUSR, NULL, delete_child);
Quoted 9 lines

drivers/infiniband/ulp/ipoib/ipoib_main.c static ssize_t delete_child(struct device *dev,

Quoted 3 lines
drivers/infiniband/ulp/ipoib/ipoib_main.c +0 -0
  int ipoib_add_pkey_attr(struct net_device *dev)
  {
 

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#9 lore raw
In reply to a message not in the archive

You are right. The mlx4_port* files are world writeable in ofed 1.4.2 but not in 1.5.1.

static int mlx4_init_port_info(struct mlx4_dev *dev, int port)

{
       struct mlx4_port_info *info = &mlx4_priv(dev)->port[port];
       struct attribute attr = {.name = info->dev_name,
                                       .mode =  S_IWUGO | S_IRUGO};

- Sumeet

Quoted 6 lines · Eli Cohen

I don't understand why mlx4_port1 and mlx4_port2 have world write permissions on your system. I can't see this from the sources nor from installing ofed-1.5.1 on my system. I agree though that the permissions for port_trigger and clear_diag should be changed. We'll push a fix to OFED 1.5.2.

Quoted 63 lines
Quoted 60 lines · Sumeet Lahorani

Thanks. I realized that my earlier find command didn't capture all the files I was looking for. After your patch, the following still need to be addressed (all are mlx4 files)

# find /sys -type f -perm -222
/sys/class/infiniband/mlx4_0/diag_counters/clear_diag
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1

- Sumeet

Quoted 32 lines · Or Gerlitz
Quoted 7 lines · Sumeet Lahorani

I see the following files created under /sys which are world writeable /sys/class/net/ib0/delete_child /sys/class/net/ib0/create_child
At least the create_child & delete_child files appear to be dangerous to leave as world writeable because they result in resources allocations.

Yes, this looks bad. The below patch fixes that, I tested it on 2.6.35-rc1

[PATCH] make ipoib child entries non-world writable

Sumeet Lahorani <[email protected]> reported that the ipoib child entries are world writable, fix them to be root only writable

drivers/infiniband/ulp/ipoib/ipoib_main.c +1 -1
index df3eb8c..b4b2257 100644
@@ -1163,7 +1163,7 @@ static ssize_t create_child(struct device *dev,
       return ret ? ret : count;
 }
-static DEVICE_ATTR(create_child, S_IWUGO, NULL, create_child);
+static DEVICE_ATTR(create_child, S_IWUSR, NULL, create_child);
 static ssize_t delete_child(struct device *dev,
                           struct device_attribute *attr,

drivers/infiniband/ulp/ipoib/ipoib_main.c static ssize_t delete_child(struct device *dev, · line 1189

Quoted 8 lines
drivers/infiniband/ulp/ipoib/ipoib_main.c +1 -1
@@ -1183,7 +1183,7 @@ static ssize_t delete_child(struct device *dev,
       return ret ? ret : count;
 }
-static DEVICE_ATTR(delete_child, S_IWUGO, NULL, delete_child);
+static DEVICE_ATTR(delete_child, S_IWUSR, NULL, delete_child);
 int ipoib_add_pkey_attr(struct net_device *dev)
 {
 
 

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#26 lore raw

Re: sysfs IPoIB root owned writable files

In reply to a message not in the archive
Quoted 4 lines
Quoted 4 lines

the following files created under /sys which are world writeable
/sys/class/net/ib0/delete_child /sys/class/net/ib0/create_child
At least the create_child & delete_child files appear to be dangerous to leave as world writeable because they result in resources allocations.

Roland,

If I see a patch in linux-rdma patchwork, e.g https://patchwork.kernel.org/patch/104502 with the below patch, does this mean it will get to be reviewed/merged towards 2.6.36, or you prefer a reminder on the list?

Or.

Quoted 22 lines

Yes, this looks bad. The below patch fixes that, I tested it on 2.6.35-rc1

[PATCH] make ipoib child entries non-world writable

Sumeet Lahorani <[email protected]> reported that the ipoib child entries are world writable, fix them to be root only writable

drivers/infiniband/ulp/ipoib/ipoib_main.c +1 -1
index df3eb8c..b4b2257 100644
@@ -1163,7 +1163,7 @@ static ssize_t create_child(struct device *dev,
 
 	return ret ? ret : count;
 }
-static DEVICE_ATTR(create_child, S_IWUGO, NULL, create_child);
+static DEVICE_ATTR(create_child, S_IWUSR, NULL, create_child);
 
 static ssize_t delete_child(struct device *dev,
 			    struct device_attribute *attr,

drivers/infiniband/ulp/ipoib/ipoib_main.c static ssize_t delete_child(struct device *dev, · line 1189

Quoted 8 lines
drivers/infiniband/ulp/ipoib/ipoib_main.c +1 -1
@@ -1183,7 +1183,7 @@ static ssize_t delete_child(struct device *dev,
 	return ret ? ret : count;
 
 }
-static DEVICE_ATTR(delete_child, S_IWUGO, NULL, delete_child);
+static DEVICE_ATTR(delete_child, S_IWUSR, NULL, delete_child);
 
 int ipoib_add_pkey_attr(struct net_device *dev)
 {

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#10 lore raw

Re: root owned writable files under /sys

In reply to a message not in the archive
Quoted 4 lines · Sumeet Lahorani
# find /sys -type f -perm -222
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1

Jack, Tziporet

Can you clarify the status of the upstream kernel mlx4 multi-protocol support? looking on Linus git, I see one commit, 7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5 "mlx4_core: Multiple port type support" dated to Oct 2008, wheres ofed ships couple of patches touching this area, e.g adding the above sysfs entries. So what is the extra functionality introduced or bug/s fixed by those patches? any reason not to push them upstream?

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#12 lore raw

RE: root owned writable files under /sys

In reply to a message not in the archive
Quoted 5 lines · Or Gerlitz

Jack, Tziporet

Can you clarify the status of the upstream kernel mlx4 multi-protocol support? looking on Linus git, I see one commit, 7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5 "mlx4_core: Multiple port type support" dated to Oct 2008, wheres ofed ships couple of patches touching this area, e.g adding the above sysfs entries. So what is the extra functionality introduced or bug/s fixed by those patches? any reason not to push them upstream?

Jack is on vacation and will be back in 2 weeks
I will ask him to look at this when he is back

Tziporet

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#14 lore raw

Re: root owned writable files under /sys

In reply to a message not in the archive
Quoted 1 line · Tziporet Koren

Jack is on vacation and will be back in 2 weeks. I will ask him to look at this when he is back

All this could have been much simpler if Yevgeny was responding, he's signed on the multi-protocol related patches shipped with ofed. So far, I had hard time getting responses form him on any of the notes I sent re mlx4_en and _core

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#31 lore raw
In reply to a message not in the archive
Quoted 2 lines

I don't see it, and none of the other patches you accepted last night, in the for-next brach of yours, where are they...?

Sitting on my local system ;)
Forgot to do git push to kernel.org.

Signature · 6 lines
Roland Dreier <[email protected]> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#15 lore raw

RE: root owned writable files under /sys

In reply to a message not in the archive

Or,
The sysfs entries you refer to are actually introduced in commit 7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5. Which patches in ofed but not upstream are you referring to?

-Jack

-----Original Message-----
From: Or Gerlitz [mailto:ogerlitz-hKgKHo2Ms0FWk0Htik3J/[email protected]]
Sent: Wednesday, July 07, 2010 8:42 AM
To: Sumeet Lahorani; Jack Morgenstein; Tziporet Koren
Cc: Roland Dreier; [email protected]
Subject: Re: root owned writable files under /sys

Quoted 4 lines · Sumeet Lahorani
# find /sys -type f -perm -222
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1

Jack, Tziporet

Can you clarify the status of the upstream kernel mlx4 multi-protocol support? looking on Linus git, I see one commit, 7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5 "mlx4_core: Multiple port type support" dated to Oct 2008, wheres ofed ships couple of patches touching this area, e.g adding the above sysfs entries. So what is the extra functionality introduced or bug/s fixed by those patches? any reason not to push them upstream?

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#17 lore raw

Re: root owned writable files under /sys

In reply to a message not in the archive
Quoted 2 lines · Jack Morgenstein

The sysfs entries you refer to are introduced in commit 7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5 which patches in ofed but not upstream are you referring to?

Hi Jack,

I took another look, indeed the mlx4_port{1,2} sysfs entries are introduced in the commit you pointed on and their permissions looks okay (S_IRUGO | S_IWUSR), they are not world writable.

As for the port_trigger sysfs entry, it is introduced by a patch shipped with ofed which isn't upstream (mlx4_1190_sense_port_trigger.patch) and indeed this entry is world writable.

So the question here, if there's any reason for multi-protocol related patches such as this
guy and its such not to be pushed upstream? I failed to get any constructive response (== pathces to Roland or Dave Miller) from Yevgeny and I was hoping you could be helpful here.

Or.

Quoted 5 lines
Quoted 4 lines · Sumeet Lahorani
# find /sys -type f -perm -222
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#19 lore raw

Re: root owned writable files under /sys

In reply to a message not in the archive

Jack,

I didn't see any further response on the matter, I got customers to complain on why the port_trigger sysfs entry is world writable and I wonder why isn't this pushed upstream, once you guys do that we can fix the permissions. Also they noted that the diag_counters entry has the same problem and its also not upstream (ofed patch mlx4_0320_diag_counters_sysfs.patch), can some progress be made here?

Or.

Quoted 17 lines · Or Gerlitz
Quoted 2 lines · Jack Morgenstein

The sysfs entries you refer to are introduced in commit 7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5 which patches in ofed but not upstream are you referring to?

Hi Jack,

I took another look, indeed the mlx4_port{1,2} sysfs entries are introduced in the commit you pointed on and their permissions looks okay (S_IRUGO | S_IWUSR), they are not world writable.

As for the port_trigger sysfs entry, it is introduced by a patch shipped with ofed which isn't upstream (mlx4_1190_sense_port_trigger.patch) and indeed this entry is world writable.

So the question here, if there's any reason for multi-protocol related patches such as this
guy and its such not to be pushed upstream? I failed to get any constructive response (== pathces to Roland or Dave Miller) from Yevgeny and I was hoping you could be helpful here.

Or.

Quoted 1 line

Sumeet Lahorani wrote:

Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
# find /sys -type f -perm -222
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#21 lore raw

RE: root owned writable files under /sys

In reply to a message not in the archive

Port trigger belongs to Yevgeny P.
Please interact with him regarding this.

-Jack

-----Original Message-----
From: Or Gerlitz [mailto:ogerlitz-hKgKHo2Ms0FWk0Htik3J/[email protected]]
Sent: Thursday, November 18, 2010 11:55 AM
To: Jack Morgenstein
Cc: Sumeet Lahorani; Tziporet Koren; Roland Dreier; [email protected]; Yevgeny Petrilin
Subject: Re: root owned writable files under /sys

Jack,

I didn't see any further response on the matter, I got customers to complain on why the port_trigger sysfs entry is world writable and I wonder why isn't this pushed upstream, once you guys do that we can fix the permissions. Also they noted that the diag_counters entry has the same problem and its also not upstream (ofed patch mlx4_0320_diag_counters_sysfs.patch), can some progress be made here?

Or.

Quoted 17 lines · Or Gerlitz
Quoted 2 lines · Jack Morgenstein

The sysfs entries you refer to are introduced in commit 7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5 which patches in ofed but not upstream are you referring to?

Hi Jack,

I took another look, indeed the mlx4_port{1,2} sysfs entries are introduced in the commit you pointed on and their permissions looks okay (S_IRUGO | S_IWUSR), they are not world writable.

As for the port_trigger sysfs entry, it is introduced by a patch shipped with ofed which isn't upstream (mlx4_1190_sense_port_trigger.patch) and indeed this entry is world writable.

So the question here, if there's any reason for multi-protocol related patches such as this
guy and its such not to be pushed upstream? I failed to get any constructive response (== pathces to Roland or Dave Miller) from Yevgeny and I was hoping you could be helpful here.

Or.

Quoted 1 line

Sumeet Lahorani wrote:

Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
# find /sys -type f -perm -222
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2
/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#23 lore raw

Re: root owned writable files under /sys

In reply to a message not in the archive
Quoted 1 line · Jack Morgenstein

Port trigger belongs to Yevgeny P. Please interact with him regarding this.

I know, the thing is that I failed to get any response from him on the matter
of pushing it upstream for long time, and this is IB related patch, so I tried to pull you on that... Yevgeny, could you push that patch any time soon?

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#25 lore raw

RE: root owned writable files under /sys

In reply to a message not in the archive

Yevgeny is going to RD next week
Will see if someone can work on this here before he returns

Tziporet

-----Original Message-----
From: Or Gerlitz [mailto:ogerlitz-hKgKHo2Ms0FWk0Htik3J/[email protected]]
Sent: Thursday, November 18, 2010 3:03 PM
To: Jack Morgenstein; Yevgeny Petrilin
Cc: Sumeet Lahorani; Tziporet Koren; [email protected]
Subject: Re: root owned writable files under /sys

Quoted 1 line · Jack Morgenstein

Port trigger belongs to Yevgeny P. Please interact with him regarding this.

I know, the thing is that I failed to get any response from him on the matter
of pushing it upstream for long time, and this is IB related patch, so I tried to pull you on that... Yevgeny, could you push that patch any time soon?

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html