From: Benjamin Coddington <bcodding@redhat.com>
To: "Zé Geraldo" <zgcarvalho@gmail.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Configuring NFS with UID/GID Offset (sec=sys approach)
Date: Wed, 10 Apr 2024 13:55:22 -0400 [thread overview]
Message-ID: <64DB2D25-5A33-434B-8898-7683ADCE3C92@redhat.com> (raw)
In-Reply-To: <CABJN9r6n1mxLNqFo2nsM9gBz6LDku9kk_V6c-85pMeH=CGzEaw@mail.gmail.com>
On 9 Apr 2024, at 16:50, Zé Geraldo wrote:
> Hello,
>
> I'm seeking advice on configuring NFS to handle a specific scenario
> where the server and client have an offset in their UID/GID values. On
> the server, a UID/GID translates to a UID/GID + 10000 on the client
> side.
>
> Ideally, I'd like to avoid modifying server configurations or changing
> client UIDs at this time.
>
> My current approach involves utilizing the sec=sys option with an
> offset to bridge this UID/GID gap. However, I'm unsure about the
> effectiveness of this method and would appreciate any insights from
> the community about how I could do this.
>
> Here's a summary of the situation:
>
> Problem: Server and client have a UID/GID offset (server UID/GID =
> client UID/GID + 10000)
> Goal: Configure NFS to handle this offset without server config
> changes or client UID modifications.
> Possible Solution (under consideration): Using sec=sys with an offset
> in the mount options.
>
> While alternative configurations like sec=krb5 functioned in a test
> environment, modifying the server configuration is not preferred.
>
> If anyone has experience with similar scenarios or can offer guidance
> on using sec=sys with offsets for NFS, your expertise would be greatly
> appreciated.
>
> Thanks,
>
> José Geraldo
Hi José,
Have you looked into whether user namespaces on top of NFS can solve your
problem? I haven't specifically used them on NFS, but it might be an
existing tool you can build upon. When you set them up, you can specify a
mapping; see user_namespaces(7). A more in-depth explanation of how they
work is here:
https://docs.kernel.org/filesystems/idmappings.html#general-notes
You must know that sec=sys doesn't provide real security, though. As long
as a particular NFS client has sec=sys access to a server, processes on that
client can impersonate any UID/GID.
Ben
prev parent reply other threads:[~2024-04-10 17:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 20:50 Configuring NFS with UID/GID Offset (sec=sys approach) Zé Geraldo
2024-04-10 17:55 ` Benjamin Coddington [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64DB2D25-5A33-434B-8898-7683ADCE3C92@redhat.com \
--to=bcodding@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=zgcarvalho@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).