On Thu, 5 Aug 2010 22:48:21 +0400
"Igor Druzhinin" <jaxbrigs@xxxxxxxxx> wrote:
> > I pulled down your latest code and it doesn't appear to be patched. Am
> > I missing something?
>
> ----------------[snip]---------------
> struct command {
> int (*action)(int argc, char *argv[]);
> const char name[MAX_COMMAND_SIZE];
> const char *format;
> };
> ----------------[snip]---------------
>
> Now, under each field we will allocate exactly MAX_COMMAND_SIZE bytes.
> During the comparison we will not walk outside the allocated area.
>
> ----------------[snip]---------------
> n = strnlen(argv[1], MAX_COMMAND_SIZE);
>
> for (cmd = commands; cmd->action; cmd++) {
> if (memcmp(cmd->name, argv[1], n) != 0)
> continue;
> ----------------[snip]---------------
Ahh ok, thanks for clarifying. I had envisioned fixing this another
way, but this should be fine.
Now that that's fixed, I think this piece is pretty much done. When you
get time, please post it as a patch to cifs-utils to the linux-cifs
mailing list so that others can comment. If no one has objections, I'll
plan to merge it soon.
> Yes, I have developed an algorithm and wrote some code samples.
> This will require some changes in mount.cifs. The kernel will look for the
> key during parsing of pass= option in cifs_parse_mount_options routine. As
> an option pass= follows the options ip=, user= and dom= problems shouldn't
> arise. If successful, password will be used from the key, otherwise from the
> pass= option. mount.cifs can independently verify the presence of the key
> and does not require a password from the user.
Cool -- I look forward to seeing that part.
I don't think however that you should assume that mount options come in
any particular order. We do occasionally get people who use cifs
without a mount helper at all or who pass in options that the mount
helper would ordinarily fill out itself (ip=, for instance).
Nice work!
--
Jeff Layton <jlayton@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
