>>>> What my patch does is to run the map script under the UID of the user requesting the mount, rather than root.
>>>> That is actually an improvement of the security situation, AFAICS.
>>
>> Possibly not.
>
> Can you explain?
It won't be an improvement if it enables something that is inherently insecure.
>> Which I take to mean that if you are specifying $UID in the mount options then you've just foiled this bit, the bit that you actually want.
>
> Permission checks are done on the server.
Then why do you need to specify a specific UID at mount time?
> On the client, without unix extensions, the user/group IDs of files may be displayed wrongly.
> That may confuse users because they may not be able to open files listed as owned by themselves, but
> it's not a security problem.
OK - so now I'm confused. you mentioned the multiuser option to mount.cifs as something that enables individual users to get
their own individual access permissions. But you're also saying (above) that they won't.
It's this lack of specificity that worries me.
If we add this code
it will enable this feature
and remove this current anomaly/mis-feature
which will provide this end-user enhancement.
________________________________
This e-mail was sent by GlaxoSmithKline Services Unlimited
(registered in England and Wales No. 1047315), which is a
member of the GlaxoSmithKline group of companies. The
registered address of GlaxoSmithKline Services Unlimited
is 980 Great West Road, Brentford, Middlesex TW8 9GS.
--
To unsubscribe from this list: send the line "unsubscribe autofs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
