Hi Guennadi,
On Wed, 8 Feb 2012 16:59:43 +0100 (CET)
Guennadi Liakhovetski <g.liakhovetski@xxxxxx> wrote:
...
> > > > +
> > > > +del:
> > > > + ret = unlink(name);
> > > > + if (ret) {
> > > > + fprintf(stderr, "Cannot delete %s: %s\n",
> > > > + name, strerror(errno));
> > > > + *resp_code = PIMA15740_RESP_GENERAL_ERROR;
> > >
> > > If you accept my proposal to just try to unlink, you'd check for EACCESS /
> > > EPERM here, and then set PIMA15740_RESP_OBJECT_WRITE_PROTECTED response
> > > code, otherwise PIMA15740_RESP_GENERAL_ERROR.
> >
> > No, this won't work. EPERM is set if the file system doesn't allow
> > unlinking of files. EACCESS is set if write access to the directory
> > containing the file is not allowed for the process's effective UID, or
> > if one of the directories in the path to the file didn't allow search
> > permission. If we want to allow deletion of files in the image directory
> > neither of these conditions must be true, anyway. unlink() successfully
> > deletes the file even if this file doesn't grant write permissions.
> > unlink() is allowed to delete the file even if it is owned by another
> > user. Having write permission to the directory containing the file is
> > enough to delete the file.
>
> You're right. Still, I would prefer to use a different approach if
> possible. What if we try to truncate(2) the file instead? That should fail
> without write permissions for the file, right?
Yes, using truncate(2) should be possible. I'll change to truncate, do
some tests and then resubmit.
Thanks,
Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
