On Mon, 2013-02-18 at 15:41 +0100, Martin Wilck wrote:
> Ian,
>
> thanks for your review.
>
> > One thing that concerned me about doing this is breaking peoples
> > program
> > maps that assume privilege they previously had.
>
> I had that concern, too. All I can say is that dropping root priviliges
> doesn't seem to have negative impact for NFS (auto.net). But other,
> user-made program maps may be affected. Perhaps people on this mailing
> list using non-standard map programs could give this patch a try?
>
> There might be another problem on multiuser systems, related to autofs'
> caching. In a Kerberos realm, one user may see other shares on a given
> server than another. For example, assume that joe sees //host/joe and
> eve sees //host/eve only. So if joe lists /cifs/host/, autofs will use
> joe's credentials and see only the "joe" share. Then if tilly tries to
> access /cifs/host/eve, she will get "no such file or directory", at
> least as long as automount thinks its cache is valid. (I haven't
> observed this myself, it's just a theoretical consideration). Anyway,
> without this patch, neither joe nor eve could use autofs + kerberos at
> all, so this may be a minor problem.
>
> > OTOH, setting the uid to
> > the caller is definitely what should be done, IMHO.
> >
> > The other thing that comes to mind is that it would be better to set the
> > same environment that non-program maps have, such as $HOME, $UID, etc.
> > for the values in the thread specific key, but that's a bit more work.
> > For non-program maps these values are added to the macro variables table
> > so they can be accessed within the map entry but for program maps the
> > environment variables need to be set instead, actually like your first
> > revision.
>
> Just to make sure that I understand correctly - do you prefer the first
> revision? Do you want me to submit a revised patch?
All I'm really saying is that, the program map returns a string that is
then used as the map entry, so when it is parsed the variables $UID,
$GID, etc. will be present in the macro lookup table as ${UID} (and $UID
etc. works) ... so maybe these same variables should be provided in the
environment of the program.
It isn't entirely clear if that is needed since those macro values may
be returned in the map entry text with things like echo "/some/string
\ ... ${UID} ..." etc. for later translation.
Really, a revised patch depends on this question being answered first.
Ian
--
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
