<div>Hi.</div><div> </div><div>> Basically I'm still blocked by the fact I can't _test_ this stuff. I<br>> don't have an environment I can boot up under kvm with a toolchain<br>> with smack headers installed so I can build this and run the result.<br>> So if I make any changes, I can't try the result. (Somebody mentioned<br>> poky? Is there an ISO image I can install under kvm?)</div><div> </div><div>Regarding testing environment, </div><div>Can you use the Tizen SDK (including emulator) ? It is helpful to test SMACK and related things..</div><div> </div><div>==============================================================</div><div>Message: 3<br> Date: Wed, 22 Apr 2015 18:45:13 +0200<br> From: Jos? Bollo <<a href="mailto:jobol@nonadev.net">jobol@nonadev.net</a>><br> To: Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>><br> Cc: toybox <<a href="mailto:toybox@lists.landley.net">toybox@lists.landley.net</a>><br> Subject: Re: [Toybox] Integration of SMACK<br> Message-ID: <<a href="mailto:1429721113.5020.1.camel@nonadev.net">1429721113.5020.1.camel@nonadev.net</a>><br> Content-Type: text/plain; charset="utf-8"<br><br> Le samedi 18 avril 2015 ? 09:37 -0500, Rob Landley a ?crit :<br>> On Fri, Apr 17, 2015 at 4:29 AM, Jos? Bollo <<a href="mailto:jobol@nonadev.net">jobol@nonadev.net</a>> wrote:<br>> > Hi all,<br>> > <br>> > I've just abandonned my 3 pull requests and created a new one. It<br>> > includes improvements suggested by Rob ibn a private discussion.<br>> > <br>> > Feedbacks are welcome<br>> <br>> I merged the first patch in the list, fluffing out the #ifdef/#else<br>> for smack in portability.h, but the second commit is another one of<br>> those "this has nothing to do with smack but you've made it a<br>> prerequisite to all the patches that _are_ about smack" patch.<br>> Specifically:<br>> <br>> From f84019f3c40c4193051e0eb4f3d4cb5313f3f5ed Mon Sep 17 00:00:00 2001<br>> From: Jan Cybulski <<a href="mailto:j.cybulski@samsung.com">j.cybulski@samsung.com</a>><br>> Date: Fri, 17 Oct 2014 08:59:24 +0200<br>> Subject: [PATCH 2/9] ls: Fix identation of number of blocks and inodes<br>> <br>> Identation was not properly done, which was especially seen with -l option.<br>> <br>> Change-Id: I681f6f0b8cf105f7f88f0dfc7779718895f9521c<br>> Signed-off-by: Jan Cybulski <<a href="mailto:j.cybulski@samsung.com">j.cybulski@samsung.com</a>><br>> <br>> Define "not properly done". There's no test to show the problem, and<br>> no description of the problem that would let me know what problem the<br>> developer thinks this fixed. I just checked the -l option again and<br>> it's calculating all the column offsets like it always was and they<br>> look fine to me?<br><br> Jan is correct, I tried the following command "ls -is" and the result is<br> not well formatted because the size of the numbers are not well<br> computed. And the count of collum is also badly computed as the space<br> between columns are not taken into account, see companion GIF image.<br><br>> I tried applying your ls patch without this, but got blocked on the<br>> fact your patch modifies bits of the previous patch (in at least one<br>> case undoing a change the earlier patch made), so there are multiple<br>> failed hunks.<br>> <br>> Meanwhile, your ls patch fetches and then frees the same absolute path<br>> three times, which is redundant. It queries data using a potentially<br>> long path, which is racy and inefficient, and doesn't match the rest<br>> of the dirtree stuff which uses openat() and friends.<br><br> After mining the question, the problem can be divided in several parts.<br><br> 1. Why the functions (l)getxattr don't have the (l)getxattr(at) variant<br> in there API? Typing "man syscalls" (with a tailing s) and searching in<br> that manual shows that it doesn't exist event at the kernel ABI level.<br> Thus it can not be used.<br><br> 2. Why the API of dirtree doesn't have a scratch buffer of at most<br> PATH_MAX to provide the same behaviour? Well it would be easier than<br> changing ABI of the kernel. Having a scratch buffer might be easy. The<br> same function, dirtree_path, could return always the same scratch<br> buffer. If you need it for a long period or because of it can be<br> overwritten, just strdup it and later free it.<br><br>> I don't see a getxattr() variant that lets us feed it a directory<br>> descriptor instead of using curdir() (apparently not many kernel<br>> developers ever actually use this syscall), but it does at least have<br>> fgetxattr() which can presumably be stacked on openat(). Or at least<br>> it could in a sane world, but this is security theatre code we're<br>> talking about here so "sane" is a big assumption: how do I know it<br>> isn't going to veto an O_RDONLY open of the file even before anybody<br>> tries to read data from it, so we can't actually get an inactive<br>> filehandle to this thing we can use to query extended attributes but<br>> not read file contents from...?<br><br>> Basically I'm still blocked by the fact I can't _test_ this stuff. I<br>> don't have an environment I can boot up under kvm with a toolchain<br>> with smack headers installed so I can build this and run the result.<br>> So if I make any changes, I can't try the result. (Somebody mentioned<br>> poky? Is there an ISO image I can install under kvm?)<br><br> I put the subject on my todo list.<br><br> Regards<br> Jos? Bollo<br><br><br>> Rob<br>> _______________________________________________<br>> Toybox mailing list<br>>  <a href="mailto:Toybox@lists.landley.net">Toybox@lists.landley.net</a><br>>  <a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a></div>