[Toybox] Integration of SMACK

[José Bollo]

Le mercredi 29 avril 2015 à 13:58 -0500, Rob Landley a écrit :
> 
> On 04/22/2015 11:45 AM, José Bollo wrote:
(snip)

> > 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.
> 
> The reason it doesn't is PATH_MAX went away years ago. It never made
> sense: you can "mkdir -p one/two/three/four/five", cd into that, and
> them "mv ~/equally/long/tree .", and thus no matter what your "maximum"
> path value is you can always construct one in the filesystem that's
> longer, and then the tools just have to cope. (Posix specifically
> requires rm to deal with arbitrary depth, which means even my "keep an
> open filehandle per level" logic has to go; I have a design to fix that
> but don't think I've implemented it yet.)

It is a good reason.

> That's why all the modern apis work based on openat() and friends. The
> alternative is constantly changing cwd, which gets racy and evil even
> _without_ threads.

ok, it makes sense.

(snip)

> In 2.6.39 the kernel guys added the O_PATH flag:
> 
> http://man7.org/linux/man-pages/man2/open.2.html
> 
> Which allows you to open a file without read permissions. (O_RDONLY is
> zero so you can't _not_ specify "I would like read permission on this
> file". So they had to add O_PATH to say "switch off the O_RDONLY bit
> even though there isn't one".)
> 
> The point of this would be to let you open a chmod 000 file via openat()
> and then use functions like fgetxattr() on it. (And this eliminates some
> races because you can fstat() the filehandle and go "yup, this is a
> directory" before proceeding.)
> 
> I'm leaning towards rewriting your ls patch to use openat() with O_PATH
> and use that to avoid allocating, traversing, and freeing full paths
> from cwd for every file.

Agreed, also leaning toward that path.

> Of course I dunno if your security infrastructure is going to veto the
> open anyway. Still can't test it...

The issue is maybe not related to security. The reason is that both
lgetxattr and open(READ|NOFOLLOW|NOATIME) will fail if security forbids
the read. The consistency of access time of the file can be managed with
NOATIME.

Best regards
José

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



 1430378067.0