[Toybox] Integration of SMACK

[José Bollo]

Le samedi 18 avril 2015 à 09:37 -0500, Rob Landley a écrit :
> On Fri, Apr 17, 2015 at 4:29 AM, José Bollo <jobol at nonadev.net> wrote:
> > Hi all,
> >
> > I've just abandonned my 3 pull requests and created a new one. It
> > includes improvements suggested by Rob ibn a private discussion.
> >
> > Feedbacks are welcome
> 
> I merged the first patch in the list, fluffing out the #ifdef/#else
> for smack in portability.h, but the second commit is another one of
> those "this has nothing to do with smack but you've made it a
> prerequisite to all the patches that _are_ about smack" patch.
> Specifically:
> 
> From f84019f3c40c4193051e0eb4f3d4cb5313f3f5ed Mon Sep 17 00:00:00 2001
> From: Jan Cybulski <j.cybulski at samsung.com>
> Date: Fri, 17 Oct 2014 08:59:24 +0200
> Subject: [PATCH 2/9] ls: Fix identation of number of blocks and inodes
> 
> Identation was not properly done, which was especially seen with -l option.
> 
> Change-Id: I681f6f0b8cf105f7f88f0dfc7779718895f9521c
> Signed-off-by: Jan Cybulski <j.cybulski at samsung.com>
> 
> Define "not properly done". There's no test to show the problem, and
> no description of the problem that would let me know what problem the
> developer thinks this fixed. I just checked the -l option again and
> it's calculating all the column offsets like it always was and they
> look fine to me?

Jan is correct, I tried the following command "ls -is" and the result is
not well formatted because the size of the numbers are not well
computed. And the count of collum is also badly computed as the space
between columns are not taken into account, see companion GIF image.

> I tried applying your ls patch without this, but got blocked on the
> fact your patch modifies bits of the previous patch (in at least one
> case undoing a change the earlier patch made), so there are multiple
> failed hunks.
>
> Meanwhile, your ls patch fetches and then frees the same absolute path
> three times, which is redundant. It queries data using a potentially
> long path, which is racy and inefficient, and doesn't match the rest
> of the dirtree stuff which uses openat() and friends.

After mining the question, the problem can be divided in several parts.

1. Why the functions (l)getxattr don't have the (l)getxattr(at) variant
in there API? Typing "man syscalls" (with a tailing s) and searching in
that manual shows that it doesn't exist event at the kernel ABI level.
Thus it can not be used.

2. Why the API of dirtree doesn't have a scratch buffer of at most
PATH_MAX to provide the same behaviour? Well it would be easier than
changing ABI of the kernel. Having a scratch buffer might be easy. The
same function, dirtree_path, could return always the same scratch
buffer. If you need it for a long period or because of it can be
overwritten, just strdup it and later free it.

> I don't see a getxattr() variant that lets us feed it a directory
> descriptor instead of using curdir() (apparently not many kernel
> developers ever actually use this syscall), but it does at least have
> fgetxattr() which can presumably be stacked on openat(). Or at least
> it could in a sane world, but this is security theatre code we're
> talking about here so "sane" is a big assumption: how do I know it
> isn't going to veto an O_RDONLY open of the file even before anybody
> tries to read data from it, so we can't actually get an inactive
> filehandle to this thing we can use to query extended attributes but
> not read file contents from...?

> Basically I'm still blocked by the fact I can't _test_ this stuff. I
> don't have an environment I can boot up under kvm with a toolchain
> with smack headers installed so I can build this and run the result.
> So if I make any changes, I can't try the result. (Somebody mentioned
> poky? Is there an ISO image I can install under kvm?)

I put the subject on my todo list.

Regards
José Bollo


> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ls.gif
Type: image/gif
Size: 54168 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20150422/200c3650/attachment-0005.gif>