We have had a few requests for optionally sending the "FILE_OPEN_FOR_BACKUP_INTENT" flag on open - as it is used by various CIFS servers (including Windows) to allow certain privileged users to backup files more easily (see quote from MS-CIFS protocol specification below). There are few reasonable ways that I see to optionally request that such a flag be sent on the wire, given that POSIX AFAIK has no exact equivalent open flag, and it is unreasonable to expect that applications would be recoded to add support for a new flag like this until other file systems have equivalents. One way would be to allow an ioctl or /proc/sys or /proc/fs setting that turns on (or off) the flag - but it is hard to imagine how that would help since the flag is specified on open. A more obvious way, following Shirish's suggestion of a "backup" mount. All opens on this mount would get the backup intent flag set - and since opens with this flag require a privileged user (with the "backup operator" right) the idea suggested below is to forbid "multiuser" behavior on such a mount. If you mount a cifs share for backup - all opens are done with the userid specified on the mount and with the backup intent flag. That seems workable - and appears to address the user requirement. If any other approach for sending this flag makes more sense though it would be helpful to get suggestions ... On Wed, Aug 24, 2011 at 9:53 PM, Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > On Tue, Aug 23, 2011 at 8:44 PM, Steve French <smfrench@xxxxxxxxx> wrote: >> I agree - but want to have a stronger argument why multiuser doesn't >> make sense and would conflict. We need to establish whether: >> 1) opens with backup intent can fail, where a normal open (without the >> flag) would work > > I think this can happen, based on this description in MS-CIFS. > > FILE_OPEN_FOR_BACKUP_INTENT 0x00004000 > The file is being opened or created for the purposes of either a > backup or a restore operation. Thus, the server can make appropriate > checks to ensure that the caller is capable of overriding whatever > security checks have been placed on the file to allow a backup or > restore operation to occur. The server can check for certain access > rights to the file before checking the DesiredAccess field. > >> 2) whether there are users for which backup intent opens will always >> work (or work no differently than the same open without the flag) - no >> matter who the owner of the file. >> >> If the latter is true then we can make the argument that for "backup" >> mounts you can only use one user. > > So the latter is true and a case of backup mount option being > mutually exclusive to multiuser option. -- Thanks, Steve -- 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
