2000-11-06 21:22:27

by Karel Zatloukal

[permalink] [raw]
Subject: Announce: NFS-client & NIS-client UID/GID remapper

Hi

On the following URL is some patches package to implement UID/GID remapping for
client. The real original purpose was to use a remapping table of 16-bit
limited Linux to be able to use 32-bit UID/GIDs of Solaris NFS and NIS server:

http://vellum.cz/~kamzik/idmapper-3.tar.gz

As the 32-bit UID/GID capabilities have been already implemented to Linux, I'm
providing this package only if there would still be some interest in it. This
package doesn't contain any 16-bit related code, it is fully 32-bit general
remapper (no 16-bit compatibility kludge code) so you can use it for tuning for
your needs of any remote NFS/NIS server maintained by 'foreign' administrator.

As a feature it also supports general regex rewriting rules for NIS client (to
enable adjusts like "/bin/ksh -> /bin/bash" etc.).

This package patches the following software:

glibc-2.1.3
No pre-glibc-2.2.x patches done, it would be patched only when wanted.
This patch contains the NIS-client part of the functionality.

linux-2.2.17
&
linux-2.4.0-test10
This patch contains the NFS-client kernel part of the functionality.

util-linux-2.10f
This patch contains the NFS-client userland part of the functionality
by implementing "idmapuid", "idmapgid" and "idmapfile" options for
mount(8) command.


All the code was only in testing phase and it was (due to organizational
issues) never been used in company-wide environment. Also beware that the real
testing was done in kernel-2.4.0-test5 time, from such time it was only updated
(almost never needed or a little bit) for kernel changes. Any bug reports in
the case of any interest would be solved. Although the patches are found in
RedHat-6.2 subdirectory, you can use it for its original package, of course.

Have these patches a chance to be mainstream integrated (in the case of any
interest by people)? Documentation excluding some /etc/idmapper.conf notes
below not yet written as I didn't want to do virtually needless work.


Nice remapping,
Karel Zatloukal



##############################################################################
#
# Mount options:
# --------------
# idmapuid=[<domainname>/]<client UID>:<server UID>
# idmapgid=[<domainname>/]<client GID>:<server GID>
# idmapfile=<filename>
#
# "/etc/idmapper.conf" is loaded automatically _after_ all the options.
# - this can be disabled by "idmapfile=-" option
# <domainname> is ypdomainname(1) value by default
#
# /etc/idmapper.conf syntax:
# --------------------------
# uid <client> <server>
# gid <client> <server>
# domain <full.domain.name:? * permitted, ypdomainname(1) is default>
# map <nismap:? * permitted> [key {uid|gid}] [uid <x>] [gid <y>]
# regex <nismap> {key|value} {from_server|to_client} <left_side:\space or chars> <right_side:\space, \0..\9 or chars>
# ... {from_client|to_server} ... # not used much: only yp_update for NIS master update(!)
#
##############################################################################
# Testing only, don't use:
## domain *
## uid 502 101010
## uid 0 231
## gid 100 202020
## domain domain.somewhere.world
## uid 502 91273
## gid 100 91273
## # Nice name wrapper, only to test regex:
### regex passwd value from_server ^(([^:]*:){4})([^:]*)\ ([^:]*)(:.*)$ \1>>name>>\3<|>\4<<name<<\5


2000-11-06 23:22:10

by Albert D. Cahalan

[permalink] [raw]
Subject: Re: Announce: NFS-client & NIS-client UID/GID remapper

The UID/GID mapper should be sepatate from the regex rewriting rules.
Both should be separate from NFS, because they have little to do with NFS.
These are useful generic VFS features. It would be perfectly reasonable
to use these features on a Zip disk with UFS (from MacOS X maybe).

Another example: given two Linux boxes with existing user accounts,
how does one merge them together into one box? The UID/GID remapper
could be helpful for this; just put both disks in the same box and
remap as needed.

The pathname remapper might best be done as a namespace operation
similar to mounting. Given a read-only /usr on CD-ROM or NFS with
an exploitable /usr/bin/suidperl, I'd like to "mount" a new
executable on top of that from /bin/good-suidperl to fix the hole.
Even more interesting is the case where /usr/bin/setuidperl does
not exist at all, so there isn't anything to use for a mount point,
but I have scripts that need to use it.

2000-11-13 05:36:52

by Karel Zatloukal

[permalink] [raw]
Subject: Re: Announce: NFS-client & NIS-client UID/GID remapper

On Mon, Nov 06, 2000 at 06:21:24PM -0500, Albert D. Cahalan wrote:
>
> The UID/GID mapper should be sepatate from the regex rewriting rules.

This is already done - the code is independent, it is just written in the same
source file. Any problems from it?

> Both should be separate from NFS, because they have little to do with NFS.
> These are useful generic VFS features. It would be perfectly reasonable
> to use these features on a Zip disk with UFS (from MacOS X maybe).

Hmm... You are perfectly right, oops.

There is only a bit of technical detail how to set such mapping: Currently I'm
using the "struct nfs_mount_data" which can contain any passed id-mapping
table. When it would be filesystem-general, it would need different solution
("data" mount(2) argument is passed only as textstring, not as flexible
'struct' as in NFS case). Probably to pass it by ioctl() call after the
mount(2) call has been done.

OK, I've todolisted this better generic-VFS approach, thanks. B ut I'll
implement it with some delay (busy etc).

...
> The pathname remapper might best be done as a namespace operation
> similar to mounting.
...
> an exploitable /usr/bin/suidperl, I'd like to "mount" a new
> executable on top of that from /bin/good-suidperl to fix the hole.

Such pathname remapper may be nice but it IMHO doesn't correspond to any code
written for announced idmapper. This would be a nice but completely separate
feature. Just to clarify - I have previously written:

# As a feature it also supports general regex rewriting rules for NIS client (to
# enable adjusts like "/bin/ksh -> /bin/bash" etc.).

This has the purpose to change the NIS line itself to prevent such hacking as
simulating some /bin/ksh etc.


Karel Zatloukal