Dear Steinar,
The nfs-kernel-server seems to silently ignore the map_daemon option. I
don't know whether uid/gid mapping via ugidd is a feature of
nfs-kernel-server or not, i.e. whether map_daemon should work at all,
however silently ignoring the option has (maybe mild, feel free to
adjust the proposed severity) security implications:
I'm not sure what the option is even supposed to do. The only reference I can
find to it is in a commented-out section of the exports man page; I believe
it's parsed for legacy reasons only.
The option is valid for nfs-user-server (and works just fine in my
setup), 'man exports' (with nfs-user-server package installed) gives a
detailed description about it (better than I can do).
Anyhow, NFSv4 does away with the uid stuff completely, so I'm not sure how
relevant this is.
I think that it is still relevant, since it is supported in
nfs-user-server and not anybody will switch to NFSv4 immediately.
I could of course make a patch that just removes the
map_daemon handling, but I'm unsure whether it has any uses at all.
In my opinion, that would be the right thing to do, also for upstream.
Also note
if (exp->m_export.e_maptype != CLE_MAP_IDENT) {
xlog(L_ERROR, "%s: unsupported mapping; kernel supports only
'identity' (default)",
exp->m_export.m_path);
errno = EINVAL;
return 0;
}
so it looks like it _should_ just give an error. Any ideas?
That is interesting. Where is that message supposed to show up? I can
find it neither in dmesg nor in kern.log nor in syslog.
Best regards,
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
