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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
