[Toybox] Regarding smack behavior of ls command

Hyejin Kim hj8296 at gmail.com
Mon May 18 03:35:08 PDT 2015


Hi.

I checked https://github.com/jobol/toybox/tree/smack-10 and It is good
to make common lib/security.h

And, found that seclabel() still calls __security_fget_context()__ only,
without handling fd failed cases.

According to your opinion as below :


* if getting file descriptor is either not possible (symbolic links,
socket) or returns an error, then get the path, else use the file
descriptor.*

Could you modify here if necessary? I want to know any direction.
Further, Can I know your test environment?

Thank you.



2015-05-18 16:48 GMT+09:00 José Bollo <jobol at nonadev.net>:

> Le lundi 18 mai 2015 à 12:26 +0900, Hyejin Kim a écrit :
> > Hi.
> >
> > Recently smack feature is added by ls command only and I tested it on
> > emulator of tizen platform.
> > But, some operations are not proper at my point of view and I'll share
> > them.
> >
> > Below is the smack code at seclabel().
> >
> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
> >   } else if (CFG_TOYBOX_SMACK) {
> >     int fd = openat(dirtree_parentfd(dt), dt->name, O_PATH|
> > O_NOFOLLOW);
> >     char buf[SMACK_LABEL_LEN+1];
> >     ssize_t len = 1;
> >     strcpy(buf, "?");
> >     if (fd != -1) {
> >       len = fgetxattr(fd, XATTR_NAME_SMACK, pad?buf:0,
> > pad?SMACK_LABEL_LEN:0);
> >       close(fd);
> >       if (len<1 || len>SMACK_LABEL_LEN) len = 0;
> >       else buf[len] = 0;
> >     }
> >     if (pad) printf(" %*s "+(pad>0), pad, buf);
> >     return len;
> >   }
> >
> >
> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
> >
> > 1. At first, fd is wrong. So, cant call fgetxattr() and print ? for
> > label.
>
> Hi Hyejin, hi all,
>
> yes it is normal, opening with O_PATH doesn't allow to call fgetxattr.
>
>
> > 2. 3rd and 4th param of fgetxattr() is changable for __pad__. but why
> > should the __pad__ affect them?
>
> Having pad=0 means that only the size of the label is checked but the
> label has not to be printed. Thus the only meaningful data is the
> length. Passing a buffer would imply some unneeded copies of memory.
>
> > 3. If it is hard to get fd, can change to call getxattr() with
> > filepath instead of calling fgetxattr with fd. I got a right result on
> > emulator with belowing example.
>
> True. But having a file descriptor instead of a path is optimal.
>
> In my last proposal https://github.com/jobol/toybox/tree/smack-10 this
> algorithm is used:
>
>  if getting file descriptor is either not possible (symbolic links,
> socket) or returns an error, then get the path, else use the file
> descriptor.
>
> For most objects of the file system: regular files and directories, the
> file descriptor is used.
>
> Best regards
> José Bollo
>
> > For example :
> >
> >
> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
> >   } else if (CFG_TOYBOX_SMACK) {
> >     char* path = dirtree_path(dt, 0);
> >     char buf[SMACK_LABEL_LEN+1];
> >     ssize_t len = 1;
> >     strcpy(buf, "?");
> >     if (path) {
> >       len = getxattr(path, XATTR_NAME_SMACK, buf, SMACK_LABEL_LEN);
> >       if (len<1 || len>SMACK_LABEL_LEN) len = 0;
> >       else buf[len] = 0;
> >     }
> >     printf(" %*s "+(pad>0), pad, buf);
> >     return len;
> >   }
> >
> >
> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
> >
> > Can anyone give me an opinion?
> >
> > Thanks.
> >
> >
> > _______________________________________________
> > Toybox mailing list
> > Toybox at lists.landley.net
> > http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20150518/f9cc1ae9/attachment-0004.htm>


More information about the Toybox mailing list