[LU-9336] ssk: documentation of -d flag of lgss_sk is incomplete Created: 13/Apr/17 Updated: 08/Jul/17 Resolved: 01/May/17 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.9.0 |
| Fix Version/s: | Lustre 2.10.0 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Kit Westneat | Assignee: | Chris Hanna |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Rank (Obsolete): | 9223372036854775807 |
| Description |
|
The documentation of the -d flag on lgss_sk only identifies is as setting the "Key random data source" but it also causes the shared key to be regenerated, regardless of the other flags. When converting a server shared key to a client one, it's necessary to use the -m modification flag to change the type attribute of the key. If one uses the -d flag as well, it will rewrite the shared key portion of the keyfile as well, and this behavior is not documented anywhere. This causes errors like: Handling sk request Decoded netstring of 653 bytes Creating credentials for target: test-MDT0000-mdc-ffff88003c228800 with nodemap: default Searching for key with description: lustre:test:default HMAC verification error: 0x60000 from peer 192.168.122.2@tcp sending reply writing message:... It would be nice if this behavior was documented somewhere, though I personally feel like rewriting the shared key should be the sole domain of the -w flag. In any case, I thought I'd report this issue in case it trips up anyone else. |
| Comments |
| Comment by Chris Hanna [ 13/Apr/17 ] |
|
Similarly, I see another problem with the documentation of the ‘-d’ flag. According to the lgss_sk help:
This implies to me, and I suspect it would to others, that the data file is a source of entropy for the generation of the key. Instead, the file becomes the key, since get_key_data() just copies it in. For example, if “-d /dev/zero” is specified when creating a new key: Version: 1 This could be more clearly reflected in the help. I also agree and propose that the -m flag should not rewrite the original secret when adding the client prime, just because the -d option was specified. |
| Comment by Andreas Dilger [ 18/Apr/17 ] |
|
Kit, Chris, since you are most familiar with this code, could one of you please submit a patch to fix the man page and/or user manual. Kit, do you think that this interaction between options should be considered a defect and instead fixed in the code, rather than a comment in the man page that the user will likely not read closely before they get it wrong? |
| Comment by Chris Hanna [ 25/Apr/17 ] |
|
I can write a quick code patch to make the -m and -d flags incompatible, and fix the help text to clarify that -d specifies the data source without any additional randomization. I don't think there is any reason to use modify on the key data source, as one could just create new key. Any objections? |
| Comment by Kit Westneat [ 25/Apr/17 ] |
|
That works for me! |
| Comment by Gerrit Updater [ 26/Apr/17 ] |
|
Chris Hanna (hannac@iu.edu) uploaded a new patch: https://review.whamcloud.com/26838 |
| Comment by Gerrit Updater [ 01/May/17 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/26838/ |
| Comment by Peter Jones [ 01/May/17 ] |
|
Landed for 2.10 |