Hi, > > see, that's why I am trying to consult with you before trying to > > "muck around with this kind of code". However, you may have noticed > > that this message of yours was rather much void of any information > > that could help me in doing so. Also, you are welcome to fix the > > bug I was reporting using your understanding of the code, so I > > don't have to "muck around with this kind of code" - I really am > > not all that keen on doing so. > > > But you haven't reported a bug. > > You say that setting the mode of a device node before setting the > ownership is a security issue, *but* you have not demonstrated how this > might be exploited. > > Since device nodes are created with root ownership, setting the mode > before the ownership is *not a concern* because it can only have less > access than afterwards. actually, I even explained _how_ this could lead to temporarily wider permissions than configured, but let's trace through an example for Mr. POSIX: Assumption: /dev/foo is configured to be owned by user root, group users, mode 0646. The attacker tries to open /dev/foo for writing as a user that's not root, not a member of the group root, but a member of the group users. The Trace: action | owner | group | mode | open(O_WRONLY)? ----------------------------+-------+-------+---------+----------------- mknod(/dev/foo) | root | root | 0644(?) | no chmod(/dev/foo,0646) | root | root | 0646 | yes chown(/dev/foo,root,users) | root | users | 0646 | no Could we now take care of the bug? Oh, and would you mind explaining why the rename() could fail? Florian -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
