On Feb 25, 2015 6:21 AM, "Stephen Smalley" <[email protected]> wrote: > > On 02/25/2015 08:39 AM, William Roberts wrote: > > > > On Feb 24, 2015 6:05 PM, "심현용" <[email protected] > > <mailto:[email protected]>> wrote: > >> > >> Dear Stephen > >> > >> I always thanks to your kindly help. > >> I have some question about labeling of symbolic-link. > >> > >> I know that commit you applied labeling about symbolic link of > > devices/block/platform/. > >> > >> > > https://android.googlesource.com/platform/system/core/+/b0ab94b7d5a888f0b6920b156e5c6a075fa0741a%5E%21/ > >> > >> this commit re-factoring method lookup_best_match like that. > >> > > https://android.googlesource.com/platform/external/libselinux/+/be7f5e8814c4954aca51d3f95455c5d9d527658c%5E%21/ > >> > >> So I can use in file_contexts. > >> /dev/block/platform/.*/my-name > >> > >> But, I hope also use other file path likes /sys/class/led/*/ ... (leds > > is symbolic-link) > >> My devices are different path leds per device. > >> > >> When I use labeling /sys/class/leds/*/name , restorecon_recursive was > > stopped at leds! > >> No more continue until name. > >> > >> So I can only use file's full path at file_contexts each devices like > > that. > >> ex) > >> -one device > >> /sys/class/leds/blue/brightness > >> -the other device > >> /sys/class/leds/B/brightness > >> > >> I hope using that .. (but restorecon_recursive will be stop at leds..) > >> /sys/class/leds/*/brightness > >> > >> Cloud you please improve lookup_best_match method? > >> If i don't understand this method, please teach me using this method. > > > > IIRC the recourse version stores the hash or checks the hash of the file > > contexts in the root of the path argument. I believe if that fails its > > fatal. > > > > At a glance, It looks like setxattr is ignored on fail but do you see > > this failing > > Src/android.c > > > > if (setrestoreconlast) { size = getxattr(pathname, RESTORECON_LAST, > > xattr_value, sizeof fc_digest); if (!force && size == sizeof fc_digest > > && memcmp(fc_digest, xattr_value, sizeof fc_digest) == 0) { > > selinux_log(SELINUX_INFO, "SELinux: Skipping > > restorecon_recursive(%s)\n", pathname); return 0; } } > > That's only relevant for restorecon on ext4 partitions, not for /sys. > setrestoreconlast is set to false for /sys. It does not make sense to > even try to set those attributes on sysfs because sysfs always needs to > be labeled, not just since the last upgrade, since it is a kernel pseudo > filesystem.
Yes (quite obvious to me). If it did go down that path it would be wrong, but its not. I was initially suspecting that assuming his fc was right. I did not see the missing . in his regex. I thought when he said full path he meant restorecon full path, not fc full path. So i was suspecting that perhaps that code wasn't robust enough to skip over that case, or was failing unexpectedly. Is there any recommendation for limiting the mode on the fc entry for recursive restores of /sys. If one is only expecting symlinks should they specify -l? > > For sysfs, we prune the tree walk based on selabel_partial_match(), > which checks whether there is a partial match for the directory against > any of the file_contexts regexes. If not, then there will be no matches > for any files under the directory so we skip the directory's children. > There is a bug in 5.x where this can wrongly skip a directory's children > if the regex contains an escaped character (e.g. \. for a literal dot > character in the pathname) because the partial match logic in 5.x was an > approximation based on a prefix match due to lack of partial match > support in the bionic regex functions. In master, libselinux has > switched to using pcre, which supports partial matching functionality > and this bug has been resolved. Good to know.
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
