Jörn Engel wrote:
On Mon, 11 May 2009 13:40:11 -0700, Joel Becker wrote:
Here's v4 of reflink(). If you have the privileges, you get the
full snapshot. If you don't, you must have read access, and then you
get the entire snapshot (data and extended attributes) except that the
security context is reinitialized. That's it. It fits with most of the
other ops, and it's a clean degradation.
Let me see if I understand this correctly. File "/tmp/foo" belongs to
Joel, file "/tmp/bar" belongs to Joern. Everyone has read access to
those files. Now if you reflink them to your home directory, both files
belong to you. If I reflink them to my home directory, both files
belong to me. And if root reflinks them to /root, one file belongs to
Joel, the other to Joern. Is that correct?
yes
Because if it is, I would call that behaviour rather confusing. A
system call that behaves differently depending on who calls it - or
on whether the binary is installed suid root - is something I would like
to avoid.
Avoiding that just gives us other confusing operations unless
you have a really good alternative.
This design is very elegant, I wish I had thought of it :)
It passes the test that 99% of the time for any user (including
root), "it just works the way I want it to". In my experience,
root and setuid programs really don't want to take ownership,
they want to replicate it.
The behavior matches "cp -p" or "tar -x" and yes those are not
system calls but so what. What matters is the documentation is
clear about what happens and the most useful result occurs.
jim
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
