From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Schweizer Date: Fri, 17 Dec 2004 17:45:00 +0000 Subject: Re: Bug#286040: please allow permissions.d to follow symlinks Message-Id: MIME-Version: 1 Content-Type: multipart/mixed; boundary="----=_Part_609_20976802.1103305500621" List-Id: References: <20041217083115.GA4050@wonderland.linux.it> In-Reply-To: <20041217083115.GA4050@wonderland.linux.it> To: linux-hotplug@vger.kernel.org ------=_Part_609_20976802.1103305500621 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, 17 Dec 2004 08:45:48 -0800, Greg KH wrote: > Actually I was considering just dropping the permissions.d file > entirely, as I think we don't need it anymore. But I have not had the > time to determine if this is possible or not just yet. This sounds cool, but it will also mean, that we have bigger rules, as most of the rules will need a GROUP="" statement then. > What about the fun interaction with pam that causes device nodes to > "magically" assume other permissions. Are you objecting to that too? > That has nothing to do with udev, it only hided an udev bug for a while If you look in your archives, you will see, that I first wanted to make permissions.d follow symlinks as the proper way to handle it. As I consider myself not a very good programmer and because someone pointed out that I could use GROUP=, I made a workaround that has been merged into udev now. But I still think its abetter to make udev follow symlinks as that will keep permissions in permissions.d and remove unnecessary grouping code from symlink-scripts like cdsymlinks.sh. > I have yet to see a patch that offers such an "improvement" in this > thread. If you ever create one, I would love to see it posted on the > list for everyone to evaluate. Until then, this argument is over. > I attached a rolled-up patch against the latest udev release for your pleasure. It was taken from http://bugs.gentoo.org/show_bug.cgi?id=73064 You can credit Gregorio Guidi sns.it> for it, when you merge it. > Um, I have no control over the debian udev rules files, I just mirror in > the udev tree what the maintainer gives to me. > I use gentoo, but why do we even have different rules.d files? Can we not make as much as possible common in them? What are the differences between the distributions? With this system we have some rules missing in every distributions rules file, because bugfixes and new features are commonly applied only to one rules file. Stefan Schweizer Gentoo developer http://dev.gentoo.org/~genstef ------=_Part_609_20976802.1103305500621 Content-Type: application/octet-stream; name="udev-match-symlink-perms.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="udev-match-symlink-perms.patch" ZGlmZiAtdU5yIHVkZXYtMDQ5Lm9yaWcvZXRjL3VkZXYvZ2VudG9vL3VkZXYucGVybWlzc2lvbnMg dWRldi0wNDYvZXRjL3VkZXYvdWRldi5wZXJtaXNzaW9ucy5nZW50b28KLS0tIHVkZXYtMDQ5Lm9y aWcvZXRjL3VkZXYvZ2VudG9vL3VkZXYucGVybWlzc2lvbnMJMjAwNC0xMS0xOCAyMDozOToxNS4w MDAwMDAwMDAgKzAxMDAKKysrIHVkZXYtMDQ5L2V0Yy91ZGV2L2dlbnRvby91ZGV2LnBlcm1pc3Np b25zCTIwMDQtMTItMDEgMjE6MjI6MTUuMDk1Njc3MDgwICswMTAwCkBAIC0xMTQsNyArMTE0LDYg QEAKIHJhdy8qOnJvb3Q6ZGlzazo2NjAKIAogIyBkaXNrIGRldmljZXMKLWhkKjpyb290OmRpc2s6 NjYwCiBzZCo6cm9vdDpkaXNrOjY2MAogZGFzZCo6cm9vdDpkaXNrOjY2MAogYXRhcmFpZCo6cm9v dDpkaXNrOjY2MApkaWZmIC11TnIgdWRldi0wNDkub3JpZy9uYW1lZGV2LmMgdWRldi0wNDYvbmFt ZWRldi5jCi0tLSB1ZGV2LTA0OS5vcmlnL25hbWVkZXYuYwkyMDA0LTExLTE4IDIwOjM5OjE1LjAw MDAwMDAwMCArMDEwMAorKysgdWRldi0wNDkvbmFtZWRldi5jCTIwMDQtMTItMDEgMjE6MTg6NDIu OTQ1OTI4NzQ0ICswMTAwCkBAIC02OTUsNyArNjk1LDkgQEAKIAlzdHJ1Y3Qgc3lzZnNfZGV2aWNl ICpzeXNmc19kZXZpY2UgPSBOVUxMOwogCXN0cnVjdCBjb25maWdfZGV2aWNlICpkZXY7CiAJc3Ry dWN0IHBlcm1fZGV2aWNlICpwZXJtOworCWNoYXIgbGlua25hbWVbTkFNRV9TSVpFXTsKIAljaGFy ICpwb3M7CisJaW50IGxlbjsKIAogCXVkZXYtPm1vZGUgPSAwOwogCWRiZygiY2xhc3NfZGV2LT5u YW1lPSclcyciLCBjbGFzc19kZXYtPm5hbWUpOwpAQCAtNzk0LDYgKzc5NiwxOCBAQAogcGVybXM6 CiAJLyogYXBwbHkgcGVybWlzc2lvbnMgZnJvbSBwZXJtaXNzaW9ucyBmaWxlIHRvIGVtcHR5IGZp ZWxkcyAqLwogCXBlcm0gPSBmaW5kX3Blcm1fZW50cnkodWRldi0+bmFtZSk7CisJaWYgKHBlcm0g IT0gTlVMTCkKKwkJZ290byBwZXJtc19mb3VuZDsKKworCS8qIHRyeSB0byBtYXRjaCB0aGUgc3lt bGluayBuYW1lICovCisJZm9yZWFjaF9zdHJwYXJ0KHVkZXYtPnN5bWxpbmssICIgIiwgcG9zLCBs ZW4pIHsKKwkJc3RyZmllbGRjcHltYXgobGlua25hbWUsIHBvcywgbGVuKzEpOworCQlwZXJtID0g ZmluZF9wZXJtX2VudHJ5KGxpbmtuYW1lKTsKKwkJaWYgKHBlcm0gIT0gTlVMTCkKKwkJCWdvdG8g cGVybXNfZm91bmQ7CisJfQorCitwZXJtc19mb3VuZDoKIAlpZiAocGVybSAhPSBOVUxMKSB7CiAJ CWlmICh1ZGV2LT5tb2RlID09IDAwMDApCiAJCQl1ZGV2LT5tb2RlID0gcGVybS0+bW9kZTsK ------=_Part_609_20976802.1103305500621-- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel