On Fri, 2009-05-15 at 13:53 -0700, Joel Becker wrote: > On Fri, May 15, 2009 at 09:42:09AM -0700, Joel Becker wrote: > > On Fri, May 15, 2009 at 11:55:25AM -0400, Stephen Smalley wrote: > > > Consider a program that wants to always preserve attributes on the > > > reflinks it creates. If the interface allows the program to explicitly > > > request that behavior and returns an error when the request cannot be > > > honored, then the program knows that upon a successful return, the > > > attributes were in fact preserved. If the interface instead silently > > > selects a behavior based on the current privileges of the process and > > > gives no indication to the caller as to what behavior was selected, then > > > the opportunity for error is great. > > > > I get that. I'm looking at what the programming interface is. > > What's the standard function for "I want the fallback behavior" called? > > What's the standard function for "I want preserve security" called? > > "int reflink(oldpath, newpath)" has to pick one of the behaviors. Which > > is it? > > Ok, I've been casting about how to solve the concern and provide > a decent interface. I'm not about to give up on either. I think, > though, that we do have to let the application signal its intent to the > system. And if we're doing that, let's add a little flexibility. > I think the interface will be this (ignoring the reflinkat(2) > bit for now): > > int reflink(const char *oldpath, const char *newpath, int preserve); > > - Data and xattrs are reflinked always. > - 'preserve is a bitfield describing which attributes to keep across the > reflink: > * REFLINK_ATTR_OWNER - Keeps uid/gid the same. Requires ownership or > CAP_CHOWN. > * REFLINK_ATTR_SECURITY - Keeps the security state (SELinux/SMACK/etc) > the same. This requires REFLINK_ATTR_OWNER (the security state makes > no sense if the ownership changes). If not set, the filesystem wipes > all security.* xattrs and reinitializes with > security_inode_init_security() just like a new file. > * REFLINK_ATTR_MODE - Keeps the mode bits the same. Requires ownership > or CAP_FOWNER. > * REFLINK_ATTR_ACL - Keeps the ACLs the same. Requires > REFLINK_ATTR_MODE, as ACLs have to get adjusted when the mode > changes, and so you can't keep them the same if the mode wasn't > preserved. If not set, the filesystem reinits the ACLs as for a new > file. > - REFLINK_ATTR_NONE is 0 and REFLINK_ATTR_ALL is ~0. > > That's all the relevant attributes. The timestamps behave as > already described (ctime is now, mtime matches the source), which is the > only sane behavior for this sort of thing. > So, a copy program would reflink(source, target, > REFLINK_ATTR_NONE), a snapshot program would reflink(source, target, > REFLINK_ATTR_ALL), and someone wanting the fallback behavior can do it > easily. > In the kernel, security_inode_reflink() gets passed the preserve > bits. It's responsible for determining whether REFLINK_ATTR_SECURITY is > allowed (vfs_reflink() will already have asserted REFLINK_ATTR_OWNER). > It may do other checks on the reflink and the preserve bits, that's up > to the LSM. > For scripting, we add the we add the '-p' and '-P' to "ln -r": > > - ln -r == reflink(source, target, REFLINK_ATTR_NONE); > - ln -r -P == reflink(source, target, REFLINK_ATTR_ALL); > - ln -r -p == the fallback behavior. This is like cp(1), where "cp -p" > is best-effort. > > Does this make everyone happy? For simplicity and robustness, I would only support the none or all flags, i.e. preserve can be a simple bool. I don't think you really want to deal with the individual flags, and I don't see a use case for them. -- Stephen Smalley National Security Agency -- 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
