On Mon, Mar 30, 2009 at 11:41:20PM +0900, Ryota Ozaki wrote:
> Hi Daniel,
>
> On Mon, Mar 30, 2009 at 10:39 PM, Daniel P. Berrange
> <berrange@xxxxxxxxxx> wrote:
> > A few more small bugs
> >
> > * src/node_device.c: Don't strdup() a NULL device parent
> > * src/qemu_conf.c: Don't try to run access() on a NULL binary path
> > * src/security_selinux.c Make sure result from readlink() is NULL
> > terminated
> > * src/storage_conf.c: DOn't free 'mode' while it is still used
Patch looks fine, with the exception
[...]
> > +++ b/src/security_selinux.c Mon Mar 30 14:37:45 2009 +0100
> > @@ -303,11 +303,13 @@ SELinuxRestoreSecurityImageLabel(virConn
> > return -1;
> >
> > if (S_ISLNK(buf.st_mode)) {
> > + int n;
> > if (VIR_ALLOC_N(newpath, buf.st_size + 1) < 0)
> > return -1;
> >
> > - if (readlink(path, newpath, buf.st_size) < 0)
> > + if ((n =readlink(path, newpath, buf.st_size)) < 0)
> > goto err;
> > + buf.st_size[n] = '\0';
> newpath[n] = '\0';
>
> correct?
Yup, I doubt it would compile otherwise :-)
I'm still doubtful about this piece of code though.
Suppose you have path an absolute path to /tmp/bar, and
bar is a relative symlink to foo, you will get buf.st_size
which is 3 i.e. the length of "foo" which is insufficient
to hold the expected path /tmp/foo.
Also /tmp/bar may point to /tmp/foo, which itself points to
/tmp/very_long_filename and again readlink will fail to provide
the full path.
Seems to me that if you're to use readlink there is no other
way than to allocate a PATH_MAX (+1) buffer and use that for
the link resolution.
So ACK to a patch but using PATH_MAX instead of buf.st_size.
Another option is to add
char *virFileReadLink(const char *path);
to util.[ch], doing the encapsulation of this rather dangerous
function and modify security_selinux.c and storage_backend_disk.c
to use that instead.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list