Hi, > > > > Could we now take care of the bug? > > > > > > Do you have a proposed patch? > > > > Nope, not yet - it was part of my intention behind this thread to gain > > some understanding of the code so as to possibly be able to provide a > > patch that doesn't break the code in some other way. In particular, as > > mentioned, the purpose of the special case codepath for a pre-existing > > device node isn't all that clear to me. > > > > I guess the general ideas I have in mind are roughly: > > > > a) mknod() it under some temporary name with appropriate euid/egid and > > umask, then rename it into place. > > > > This one seems to have some issues that I can't really judge yet > > (changing inode number, ACLs being dropped). > > That will not work for the case of an existing device node, correct? Scott claims so, but so far hasn't explained why. After all, the current code does that rename()ing in case there is some device node with different device numbers under the name to be created - but maybe there is some reason for why this works even though it may not work in other cases? > > b) (optionally mknod() with mode&0600), chmod() to mode&0600, > > chown() to configured owner/group, chmod() to configured mode. > > > > This one potentially temporarily reduces permissions to a proper > > subset of both the permissions before and after the change - > > I guess that that's not desirable? > > See Scott's response as to why this isn't ok. I can't find anything as to why this wouldn't be ok in any of his emails. 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
