8:29 a.m.
Hello,
a local account on a nfs client couldn’t write to a ganesha nfs export even with directory
permissions 777. The solution was to create the account on the ganesha servers, too.
Please can you confirm that this is the intended behaviour? is there an option to change
this and to map unknown accounts to nobody instead? We often have embedded Linux
appliances or similar as nfs clients which need to place some data on the nfs exports
using uid/gid of local accounts.
We manage gids on the server side and allow NFS v3 client access only.
I crosspost this to ganesha support and to the gpfsug mailing list.
Thank you,
Heiner Billich
ganesha version: 2.5.3-ibm028.00.el7.x86_64
the ganesha config
CacheInode
{
fd_hwmark_percent=60;
fd_lwmark_percent=20;
fd_limit_percent=90;
lru_run_interval=90;
entries_hwmark=1500000;
}
NFS_Core_Param
{
clustered=TRUE;
rpc_max_connections=10000;
heartbeat_freq=0;
mnt_port=33247;
nb_worker=256;
nfs_port=2049;
nfs_protocols=3,4;
nlm_port=33245;
rquota_port=33246;
rquota_port=33246;
short_file_handle=FALSE;
mount_path_pseudo=true;
}
GPFS
{
fsal_grace=FALSE;
fsal_trace=TRUE;
}
NFSv4
{
delegations=FALSE;
domainname=virtual1.com;
grace_period=60;
lease_lifetime=60;
}
Export_Defaults
{
access_type=none;
anonymous_gid=-2;
anonymous_uid=-2;
manage_gids=TRUE;
nfs_commit=FALSE;
privilegedport=FALSE;
protocols=3,4;
sectype=sys;
squash=root_squash;
transports=TCP;
}
one export
# === START /**** id=206 nclients=3 ===
EXPORT {
Attr_Expiration_Time=60;
Delegations=none;
Export_id=206;
Filesystem_id=42.206;
MaxOffsetRead=18446744073709551615;
MaxOffsetWrite=18446744073709551615;
MaxRead=1048576;
MaxWrite=1048576;
Path="/****";
PrefRead=1048576;
PrefReaddir=1048576;
PrefWrite=1048576;
Pseudo="/****";
Tag="****";
UseCookieVerifier=false;
FSAL {
Name=GPFS;
}
CLIENT {
# === ****/X12SA ===
Access_Type=RW;
Anonymous_gid=-2;
Anonymous_uid=-2;
Clients=X.Y.A.B/24;
Delegations=none;
Manage_Gids=TRUE;
NFS_Commit=FALSE;
PrivilegedPort=FALSE;
Protocols=3;
SecType=SYS;
Squash=Root;
Transports=TCP;
}
….
--
Paul Scherrer Institut
Heiner Billich
System Engineer Scientific Computing
Science IT / High Performance Computing
WHGA/106
Forschungsstrasse 111
5232 Villigen PSI
Switzerland
Phone +41 56 310 36 02
heiner.billich@psi.ch<mailto:heiner.billich@psi.ch>
https://www.psi.ch
9:35 a.m.
Hi.
For local operating FSALs (like GPFS and VFS), the way Ganesha makes
sure that a UID/GID combo has the correct permissions for an operation
is to set the UID/GID of the thread to the one in the operation, then
perform the actual operation. This way, the kernel and the underlying
filesystem perform atomic permission checking on the op. This
setuid/setgid will fail, of course, if the local system doesn't have
that UID/GID to set to.
The solution for this is to use NFS idmap to map the remote ID to a
local one. This includes the ability to map unknown IDs to some local ID.
Daniel
On 1/24/19 9:29 AM, Billich Heinrich Rainer (PSI) wrote:
Hello,
a local account on a nfs client couldn’t write to a ganesha nfs export
even with directory permissions 777. The solution was to create the
account on the ganesha servers, too.
Please can you confirm that this is the intended behaviour? is there an
option to change this and to map unknown accounts to nobody instead? We
often have embedded Linux appliances or similar as nfs clients which
need to place some data on the nfs exports using uid/gid of local accounts.
We manage gids on the server side and allow NFS v3 client access only.
I crosspost this to ganesha support and to the gpfsug mailing list.
Thank you,
Heiner Billich
ganesha version: 2.5.3-ibm028.00.el7.x86_64
the ganesha config
CacheInode
{
fd_hwmark_percent=60;
fd_lwmark_percent=20;
fd_limit_percent=90;
lru_run_interval=90;
entries_hwmark=1500000;
}
NFS_Core_Param
{
clustered=TRUE;
rpc_max_connections=10000;
heartbeat_freq=0;
mnt_port=33247;
nb_worker=256;
nfs_port=2049;
nfs_protocols=3,4;
nlm_port=33245;
rquota_port=33246;
rquota_port=33246;
short_file_handle=FALSE;
mount_path_pseudo=true;
}
GPFS
{
fsal_grace=FALSE;
fsal_trace=TRUE;
}
NFSv4
{
delegations=FALSE;
domainname=virtual1.com;
grace_period=60;
lease_lifetime=60;
}
Export_Defaults
{
access_type=none;
anonymous_gid=-2;
anonymous_uid=-2;
manage_gids=TRUE;
nfs_commit=FALSE;
privilegedport=FALSE;
protocols=3,4;
sectype=sys;
squash=root_squash;
transports=TCP;
}
one export
# === START /**** id=206 nclients=3 ===
EXPORT {
Attr_Expiration_Time=60;
Delegations=none;
Export_id=206;
Filesystem_id=42.206;
MaxOffsetRead=18446744073709551615;
MaxOffsetWrite=18446744073709551615;
MaxRead=1048576;
MaxWrite=1048576;
Path="/****";
PrefRead=1048576;
PrefReaddir=1048576;
PrefWrite=1048576;
Pseudo="/****";
Tag="****";
UseCookieVerifier=false;
FSAL {
Name=GPFS;
}
CLIENT {
# === ****/X12SA ===
Access_Type=RW;
Anonymous_gid=-2;
Anonymous_uid=-2;
Clients=X.Y.A.B/24;
Delegations=none;
Manage_Gids=TRUE;
NFS_Commit=FALSE;
PrivilegedPort=FALSE;
Protocols=3;
SecType=SYS;
Squash=Root;
Transports=TCP;
}
….
--
Paul Scherrer Institut
Heiner Billich
System Engineer Scientific Computing
Science IT / High Performance Computing
WHGA/106
Forschungsstrasse 111
5232 Villigen PSI
Switzerland
Phone +41 56 310 36 02
heiner.billich(a)psi.ch <mailto:heiner.billich@psi.ch>
https://www.psi.ch
_______________________________________________
Support mailing list -- support(a)lists.nfs-ganesha.org
To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org
3:13 a.m.
Hello Daniel,
thank you. The clients do NFS v3 mounts, hence idmap is no option - as I know it's
used in NFS v4 to map between uid/guid and names only? For a process to switch to a
certain uid/guid in general one does not need a matching passwd entry? I see that with
ACLs you get issues as they use names, and you can't do a server-side group membership
lookup, and there may be more subtle issues.
Anyway, I'll create the needed accounts on the server. By the way: We had the same
issue with Netapp filers and it took a while to find the configuration option to allow
'unknown' uid/gid to access a nfs v3 export.
I'll try to reproduce on a test system with increased logging to see what exactly
goes wrong and maybe ask later to add a configuration option to ganesha to switch to a
behaviour more similar to kernel-nfs.
Many client systems at my site are legacy and run various operating systems, hence a
complete switch to NFS v4 is unlikely to happen soon.
cheers,
Heiner
--
Paul Scherrer Institut
Heiner Billich
System Engineer Scientific Computing
Science IT / High Performance Computing
WHGA/106
Forschungsstrasse 111
5232 Villigen PSI
Switzerland
Phone +41 56 310 36 02
heiner.billich(a)psi.ch
https://www.psi.ch
On 24/01/19 16:35, "Daniel Gryniewicz" <dang(a)redhat.com> wrote:
Hi.
For local operating FSALs (like GPFS and VFS), the way Ganesha makes
sure that a UID/GID combo has the correct permissions for an operation
is to set the UID/GID of the thread to the one in the operation, then
perform the actual operation. This way, the kernel and the underlying
filesystem perform atomic permission checking on the op. This
setuid/setgid will fail, of course, if the local system doesn't have
that UID/GID to set to.
The solution for this is to use NFS idmap to map the remote ID to a
local one. This includes the ability to map unknown IDs to some local ID.
Daniel
On 1/24/19 9:29 AM, Billich Heinrich Rainer (PSI) wrote:
Hello,
a local account on a nfs client couldn’t write to a ganesha nfs export
even with directory permissions 777. The solution was to create the
account on the ganesha servers, too.
Please can you confirm that this is the intended behaviour? is there an
option to change this and to map unknown accounts to nobody instead? We
often have embedded Linux appliances or similar as nfs clients which
need to place some data on the nfs exports using uid/gid of local accounts.
We manage gids on the server side and allow NFS v3 client access only.
I crosspost this to ganesha support and to the gpfsug mailing list.
Thank you,
Heiner Billich
ganesha version: 2.5.3-ibm028.00.el7.x86_64
2009
days inactive
2010
days old
2 comments
2 participants
participants (2)
-
Billich Heinrich Rainer (PSI) -
Daniel Gryniewicz