Minor usage string improvement

[safayetahmedatge]

The usage string for add_key, remove_key, and key_status is somewhat misleading. These commands currently describe their path argument as a MOUNTPOINT, which suggests that the argument must be the root of the filesystem.

However, the implementation simply opens the supplied path and passes the resulting file descriptor to the corresponding fscrypt ioctl. The FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY, and FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctls do not require the file descriptor to refer to the filesystem root. They can be executed on any file or directory on the target filesystem; the filesystem root is only recommended by the kernel documentation.

Consequently, a user who has a directory on the target filesystem should not need to first determine its mount point (for example, with findmnt) before using add_key, remove_key, or key_status. The current usage string implies that they do.

The usage string should therefore be generalized to describe the argument as a path on the target filesystem rather than specifically as a mount point.

For example, instead of:

fscryptctl add_key [OPTION...] MOUNTPOINT

the usage could use something like:

fscryptctl add_key [OPTION...] PATH

and similarly for remove_key and key_status.

Reference:

fscryptctl/fscryptctl.c

Lines 120 to 130 in f1ec919

	fputs(
	"\nUsage:\n"
	" fscryptctl <command> [arguments] [options]\n"
	"\nCommands:\n"
	" fscryptctl add_key <mountpoint>\n"
	" Read a key from stdin, add it to the specified mounted filesystem,\n"
	" and print its identifier.\n"
	" fscryptctl remove_key <key identifier> <mountpoint>\n"
	" Remove the key with the specified identifier from the specified\n"
	" mounted filesystem.\n"
	" fscryptctl key_status <key identifier> <mountpoint>\n"

[ebiggers]

That's true, but <mountpoint> helps convey that the operation applies to the whole filesystem. With just <path> people will sometimes do the following:

• Run fscrypt add_key dir1 and then be surprised that it also unlocks dir2 that uses the same key
• Run fscrypt remove_key dir1 and then wonder why it fails (it's because dir1 is open when the ioctl is executed)

So yes, <path> is technically correct, but a bit more prone to misuse, and we'd have to add more text that clarifies that it applies to the whole filesystem.

[safayetahmedatge]

Good point, @ebiggers. So the distinction is between the scope of the argument being passed and the scope of the effect of the command. How about this as compromise:

     "  fscryptctl add_key <path>\n" 
     "    Read a key from stdin, add it to the mounted filesystem that\n" 
     "    contains the specified path, and print the key identifier.\n" 
     ...