Based on recent discussions with Urban Widmark, regarding a patch to
smbfs, I've come up with a system for mapping "local" and "remote" UID's
and GID's to each other. "Local" means those in the user database and
"remote" means those on the filesystem in question, be it networked or
non-networked. This system enables you to mount a filesystem via NFS or
Samba (with UNIX extensions) and supply a bunch of mappings between the
UID's and GID's on the client system and those on the server system.
Whenever a local user does something on the filesystem, his UID is
mapped to his corresponding UID on the remote system. This all takes
place in the VFS system.
The system can also be used if a user were to mount a samba share that
has the UNIX extensions enabled. In this case, you'd define a default
local and a default remote UID/GID so that all files would locally
appear to be owned by the mounting user, hence allowing him to actually
access the files that the server would allow him to, without placing any
additional local restrictions on his access (if this doesn't seem to
make sense, see my previous post with subject "smbfs patch").
If you you're moving a disk from one system to another, you could use
the system to fix up the ownership instead of having to change them all
on the actual filesystem.
All in all, I think this could be very helpful.
However, I have two question:
1. I'm very new to this kernel stuff, and this might only be a good idea
inside my head. Does this sound clever or am I fixing these problems at
the totally wrong level?
2. I need a bit of help getting these mappings from the mount command
into the kernel. I'm thinking about allowing a mount option called
uidmap and one called gidmap which both take a filename as argument.
This file could look like so:
============================
# Syntax:
# local id = remote id
1000 = 1005
1001 = 1003
1002 = 1002
default = 1000
1004 = default
============================
...or something like that. I just haven't quite figured out how to have
mount read these options and pass it to the kernel to populate these map
tables. Any pointers would be greatly appreciated.
The patches to the VFS system are in place, I just want to test them
some more before posting them anywhere.
Looking forward to your input!
--
S?ren Hansen <[email protected]>
On Monday 08 March 2004 13:45, S?ren Hansen wrote:
> Based on recent discussions with Urban Widmark, regarding a patch to
> smbfs, I've come up with a system for mapping "local" and "remote" UID's
> and GID's to each other. "Local" means those in the user database and
> "remote" means those on the filesystem in question, be it networked or
> non-networked. This system enables you to mount a filesystem via NFS or
> Samba (with UNIX extensions) and supply a bunch of mappings between the
> UID's and GID's on the client system and those on the server system.
> Whenever a local user does something on the filesystem, his UID is
> mapped to his corresponding UID on the remote system. This all takes
> place in the VFS system.
> The system can also be used if a user were to mount a samba share that
> has the UNIX extensions enabled. In this case, you'd define a default
> local and a default remote UID/GID so that all files would locally
> appear to be owned by the mounting user, hence allowing him to actually
> access the files that the server would allow him to, without placing any
> additional local restrictions on his access (if this doesn't seem to
> make sense, see my previous post with subject "smbfs patch").
> If you you're moving a disk from one system to another, you could use
> the system to fix up the ownership instead of having to change them all
> on the actual filesystem.
> All in all, I think this could be very helpful.
>
> However, I have two question:
> 1. I'm very new to this kernel stuff, and this might only be a good idea
> inside my head. Does this sound clever or am I fixing these problems at
> the totally wrong level?
> 2. I need a bit of help getting these mappings from the mount command
> into the kernel. I'm thinking about allowing a mount option called
> uidmap and one called gidmap which both take a filename as argument.
> This file could look like so:
> ============================
> # Syntax:
> # local id = remote id
> 1000 = 1005
> 1001 = 1003
> 1002 = 1002
> default = 1000
> 1004 = default
> ============================
> ...or something like that. I just haven't quite figured out how to have
> mount read these options and pass it to the kernel to populate these map
> tables. Any pointers would be greatly appreciated.
> The patches to the VFS system are in place, I just want to test them
> some more before posting them anywhere.
Have you considered the problem of 64 bit uids? and gids?, and unlimited
number of groups assigned to a single user? How about having to support
multiple maps (one for each remote host that mounts a filesystem)?
I suspect not - you don't have enough memory to handle it.
These tables are going to have to be external to the kernel, and the kernel
only caching those that are known to be active to speed up the search.
This will call for an external daemon to support the dynamic mapping. Second,
you will have to have one map for each exported filesystem for each host that
is allowed to mount it. I grant that frequently there will be one map used
multiple times, but the worst case is one for each host.
To speed the external lookups up I suggest using a radix search (not my
original idea - Cray did it first).
I also suggest making it optional - or being able to specify a 1:1 mapping
be assumed. And be used with an inverse table: UIDs that are NOT to be mapped
(as in, all uids are mapped 1:1 EXCEPT ...)
I have worked at centers that had about 1200 users on each of 5 compute
servers. Each compute server mounts the same filesystem from a server. IF
and only if all systems are within one security domain (all users are common,
and have the same uid/gid list for all systems - a frequent case), do
you not need a map.
If each compute server is in a different security domain (unique user list)
then you must have 5 maps (10 if you include group maps) for each filesystem.
That adds up to 6000 entries in uid maps alone. If 64 bit uids are used (8
bytes/uid) that becomes 48K for the example, with only ONE exported
filesystem, and only uids. This might seem a lot, but consider exports to
workstations - 150 workstations, and likely 2-5 uids each (at least
one for admininistration use). That would be 150 maps (just uids), of only 5
entries each - 750 entries, 6K (more reasonable).
With Linux showing up more and more in large clusters, I expect the total
number of users to increase for the worst case result (consider 4 128 node
clusters mounting filesystems from an archive cluster: 512 mounts, with maybe
100 users for each cluster? something like 4MB for maps alone)
tir, 2004-03-09 kl. 17:46 skrev Jesse Pollard:
> Have you considered the problem of 64 bit uids? and gids?,
Er.. no. I just use the uid_t and gid_t. Are they 64bit? Why are they a problem?
> and unlimited number of groups assigned to a single user?
No. That's not my problem, is it? I just provide the mapping system.
> How about having to support multiple maps (one for each remote host
> that mounts a filesystem)?
The maps are on the client, so that's no issue. The trick is to make it
totally transparent to the filesystem being mounted, be it networked or
non-networked.
> These tables are going to have to be external to the kernel, and the kernel
> only caching those that are known to be active to speed up the search.
I suppose that would be a solution. But now that you know it's on the
client, is it still as big a problem? I don't think so, but I could be
wrong.
> I also suggest making it optional - or being able to specify a 1:1 mapping
> be assumed. And be used with an inverse table: UIDs that are NOT to be mapped
> (as in, all uids are mapped 1:1 EXCEPT ...)
That's the way it's done now. If there's no map in the file, it's just
passed through. And of course you don't have to supply any file at all!
> I have worked at centers that had about 1200 users on each of 5 compute
> servers. Each compute server mounts the same filesystem from a server. IF
> and only if all systems are within one security domain (all users are common,
> and have the same uid/gid list for all systems - a frequent case), do
> you not need a map.
Right.
> If each compute server is in a different security domain (unique user list)
> then you must have 5 maps (10 if you include group maps) for each filesystem.
> That adds up to 6000 entries in uid maps alone. If 64 bit uids are used (8
> bytes/uid) that becomes 48K for the example, with only ONE exported
> filesystem, and only uids. This might seem a lot, but consider exports to
> workstations - 150 workstations, and likely 2-5 uids each (at least
> one for admininistration use). That would be 150 maps (just uids), of only 5
> entries each - 750 entries, 6K (more reasonable).
Still, the server does not know this is going on. It's all on the
client, so the memory usage is limited.
--
S?ren Hansen <[email protected]>
tir, 2004-03-09 kl. 17:46 skrev Jesse Pollard:
> Have you considered the problem of 64 bit uids? and gids?,
Er.. no. I just use the uid_t and gid_t. Are they 64bit?
> and unlimited number of groups assigned to a single user?
No. That's not my problem, is it? I just provide the mapping system.
> How about having to support multiple maps (one for each remote host
> that mounts a filesystem)?
The maps are on the client, so that's no issue. The trick is to make it
totally transparent to the filesystem being mounted, be it networked or
non-networked.
> These tables are going to have to be external to the kernel, and the kernel
> only caching those that are known to be active to speed up the search.
I suppose that would be a solution. But now that you know it's on the
client, is it still as big a problem? I don't think so, but I could be
wrong.
> I also suggest making it optional - or being able to specify a 1:1 mapping
> be assumed. And be used with an inverse table: UIDs that are NOT to be mapped
> (as in, all uids are mapped 1:1 EXCEPT ...)
That's the way it's done now. If there's no map in the file, it's just
passed through. And of course you don't have to supply any file at all!
> I have worked at centers that had about 1200 users on each of 5 compute
> servers. Each compute server mounts the same filesystem from a server. IF
> and only if all systems are within one security domain (all users are common,
> and have the same uid/gid list for all systems - a frequent case), do
> you not need a map.
Right.
> If each compute server is in a different security domain (unique user list)
> then you must have 5 maps (10 if you include group maps) for each filesystem.
> That adds up to 6000 entries in uid maps alone. If 64 bit uids are used (8
> bytes/uid) that becomes 48K for the example, with only ONE exported
> filesystem, and only uids. This might seem a lot, but consider exports to
> workstations - 150 workstations, and likely 2-5 uids each (at least
> one for admininistration use). That would be 150 maps (just uids), of only 5
> entries each - 750 entries, 6K (more reasonable).
Still, the server does not know this is going on. It's all on the
client, so the memory usage is limited.
--
S?ren Hansen <[email protected]>
On Tuesday 09 March 2004 13:28, S?ren Hansen wrote:
> tir, 2004-03-09 kl. 17:46 skrev Jesse Pollard:
> > Have you considered the problem of 64 bit uids? and gids?,
>
> Er.. no. I just use the uid_t and gid_t. Are they 64bit?
32 bits currently.
>
> > and unlimited number of groups assigned to a single user?
>
> No. That's not my problem, is it? I just provide the mapping system.
but the mapping system has to be able to handle it.
> > How about having to support multiple maps (one for each remote host
> > that mounts a filesystem)?
>
> The maps are on the client, so that's no issue. The trick is to make it
> totally transparent to the filesystem being mounted, be it networked or
> non-networked.
The server cannot trust the clients to do the right thing. After all, the
administrator of the server is not in charge of the client. Therefore, the
server cannot trust the client. Hence, the server must perform the mapping.
> > These tables are going to have to be external to the kernel, and the
> > kernel only caching those that are known to be active to speed up the
> > search.
>
> I suppose that would be a solution. But now that you know it's on the
> client, is it still as big a problem? I don't think so, but I could be
> wrong.
As stated above, the server cannot trust the client.
> > I also suggest making it optional - or being able to specify a 1:1
> > mapping be assumed. And be used with an inverse table: UIDs that are NOT
> > to be mapped (as in, all uids are mapped 1:1 EXCEPT ...)
>
> That's the way it's done now. If there's no map in the file, it's just
> passed through. And of course you don't have to supply any file at all!
>
> > I have worked at centers that had about 1200 users on each of 5 compute
> > servers. Each compute server mounts the same filesystem from a server. IF
> > and only if all systems are within one security domain (all users are
> > common, and have the same uid/gid list for all systems - a frequent
> > case), do you not need a map.
>
> Right.
>
> > If each compute server is in a different security domain (unique user
> > list) then you must have 5 maps (10 if you include group maps) for each
> > filesystem. That adds up to 6000 entries in uid maps alone. If 64 bit
> > uids are used (8 bytes/uid) that becomes 48K for the example, with only
> > ONE exported filesystem, and only uids. This might seem a lot, but
> > consider exports to workstations - 150 workstations, and likely 2-5 uids
> > each (at least one for admininistration use). That would be 150 maps
> > (just uids), of only 5 entries each - 750 entries, 6K (more reasonable).
>
> Still, the server does not know this is going on. It's all on the
> client, so the memory usage is limited.
The server cannot trust the client. Think about it. The security domain of the
server (when using maps at all) will NOT be the same as the client. Since
different organizations are in charge of the server, how can that server trust
the client? A violation (even minor) on the client could cause a significant
violation of the server. As in a shipping department mounting a server, and a
financial client mounting from the same server - a violation on the shipping
client COULD expose financial data; and the server not even know. Or worse -
the shipping depeartment has been outsourced...
The server MUST control access to its resources.
Been there, seen that. Have NO desire to have to talk to the FBI about "due
diligence".
ons, 2004-03-10 kl. 16:28 skrev Jesse Pollard:
> > Er.. no. I just use the uid_t and gid_t. Are they 64bit?
> 32 bits currently.
Ok.. But those are the data types in use in the v-nodes, right?
> > > and unlimited number of groups assigned to a single user?
> > No. That's not my problem, is it? I just provide the mapping system.
> but the mapping system has to be able to handle it.
How do you figure that?
> > The maps are on the client, so that's no issue. The trick is to make it
> > totally transparent to the filesystem being mounted, be it networked or
> > non-networked.
> The server cannot trust the clients to do the right thing.
The server can't trust the client as it is now anyway. The client can do
whatever it wants already. There is no security impact as I see it.
> The server cannot trust the client.
I know! That's an entirely different issue. The very nanosecond you give
another machine access to your filesystem, you're up shit creek anyway.
The only difference between the way things are now and after the system
I'm suggesting is in place, is that the ownerships will look sane on the
client. What possible extra security implications could this cause?
> Since different organizations are in charge of the server, how can that server trust
> the client?
Please explain how you in any way can trust a client mounting an nfs
export from your server? You can't. All you can do is keep your fingers
crossed and your hacksaw sharpened (in case you want a more hands-on
security scheme). Maps or no maps, this is the same issue.
> A violation (even minor) on the client could cause a significant
> violation of the server.
Yes. Just like it can now.
> As in a shipping department mounting a server, and a financial client
> mounting from the same server - a violation on the shipping client COULD
> expose financial data; and the server not even know. Or worse - the
> shipping depeartment has been outsourced...
> The server MUST control access to its resources.
Yes. As always.
If you have an idea for a patch that fixes all these issues, I'll more
than happy to see it.
--
S?ren Hansen <[email protected]>
On Wednesday 10 March 2004 11:58, S?ren Hansen wrote:
> ons, 2004-03-10 kl. 16:28 skrev Jesse Pollard:
> > > Er.. no. I just use the uid_t and gid_t. Are they 64bit?
> >
> > 32 bits currently.
>
> Ok.. But those are the data types in use in the v-nodes, right?
uid_t and gid_t eventually map to an int. And on most platforms an
int is 32 bits (even Power). There are some platforms that an int is
64 bits (though Linux doesn't currently run on it). This is a
hardware issue more than a software one. The other case that speaks for
larger potential UID/GID space is when you interface to systems using a
universal uid - which is either 64 bits or 128 (I'm not sure which
is normal).
> > > > and unlimited number of groups assigned to a single user?
> > >
> > > No. That's not my problem, is it? I just provide the mapping system.
> >
> > but the mapping system has to be able to handle it.
>
> How do you figure that?
I should have said "designed to handle it" in a future expansion. I was
wrong in making 64 bits as important as it looks.
> > > The maps are on the client, so that's no issue. The trick is to make it
> > > totally transparent to the filesystem being mounted, be it networked or
> > > non-networked.
> >
> > The server cannot trust the clients to do the right thing.
>
> The server can't trust the client as it is now anyway. The client can do
> whatever it wants already. There is no security impact as I see it.
Ah - but if the server refuses to map the uid then the server is more
protected. And it can detect when mapping is in error or under some forms
of attack (not all).
First, if the server refuses to map uids into what it considers system
(say, those less than 100... or better, 1000) then the daemons that may be
using those uids/gids on the server (or other hosts even) will be
protected from a simple mapping attack. Any attempt to do so will be detected
by the server, blocked, and reported.
Second, if the various organizations are mapped, then only maps (and
uids/gids) authorized by those maps can be used. Any hanky panky on the
client host will ONLY involve those accounts/uids already on the client. They
will NOT be able to map to accounts/uids that are assigned to the other
organization. Again, attempts to access improper accounts will be detected
by the server, blocked, and reported.
This isolates any attacks to only those accounts on the compromised host.
> > The server cannot trust the client.
>
> I know! That's an entirely different issue. The very nanosecond you give
> another machine access to your filesystem, you're up shit creek anyway.
> The only difference between the way things are now and after the system
> I'm suggesting is in place, is that the ownerships will look sane on the
> client. What possible extra security implications could this cause?
It will hide the auditing to a possibly compromised system. This in turn
means that no central audit of the server will be possible.
> > Since different organizations are in charge of the server, how can that
> > server trust the client?
>
> Please explain how you in any way can trust a client mounting an nfs
> export from your server? You can't. All you can do is keep your fingers
> crossed and your hacksaw sharpened (in case you want a more hands-on
> security scheme). Maps or no maps, this is the same issue.
Currently - I can't. At least not on linux. The Cray UNICOS system has
mandatory maps on any NFS export. Any uid/gid from a remote host is mapped to
the correct local uid/gid (and this is one of the systems that has 64 bit
UIDs/GIDs). In fact - if the uid/gid of the nfs map is not correct (to permit
the NFS daemons on the client to access) then all NFS activity will fail for
that host.
> > A violation (even minor) on the client could cause a significant
> > violation of the server.
>
> Yes. Just like it can now.
Which is why UID/GID mapping must be done on the server. At the present time
the only network file system that can be supported is OpenAFS. And there, the
access rights are mediated by Kerberos credentials handled by the server, not
UID/GID.
> > As in a shipping department mounting a server, and a financial client
> > mounting from the same server - a violation on the shipping client COULD
> > expose financial data; and the server not even know. Or worse - the
> > shipping depeartment has been outsourced...
> > The server MUST control access to its resources.
>
> Yes. As always.
>
> If you have an idea for a patch that fixes all these issues, I'll more
> than happy to see it.
We've already outlined most of it. The principle is that the server must
mediate the UID/GID maps.
With this in mind, the kernel NFS processes must have one additional task when
reciving/sending uid/gid lists over the net.
When sending: lookup the local uid in a reverse map to obtain the remote uid.
Each gid must also be reverse looked up to obtain the remote
gid(s). The resulting packet can then be sent to the client.
Violations in the lookup are to be treated like a network
error and logged (the system doesn't stop - it just sends an
error packet to the client, and logs the error. Lots of errors
may automatically disable the client, but that would be a different
policy - and should be handled by the external daemon/LSM module).
When recieving: lookup the remote uid to locate the local uid.
Each gid in the packet must also be looked up to obtain the
local gid(s). The modified packet can then be processed as
it currently is. The same type of error handling as for sending.
mountd changes: interpret small uid/gid lists, provide/generate optional
connections to the daemon instance. hmm.. one daemon for each
mount? or one daemon for all... one for each mount would be
simpler to do at first - that way the daemon could be started
by mountd with a "mapper socket forward.map reverse.map" and
the maps generated by an external utility, or even just a
forward.map in ascii, and let the daemon generate binary
versions of both. This would also be easier to audit, though
more CPU bound if a bunch of workstations is done. (might not
be bad... if the UID/GID lists are small enought, no daemon
would be needed).
Optimizations:
The lookup function must be capable of using sparse tables for cached
lookups for both forward and reverse mapping (radix searching for this
type of binary data is really fast, though hashing may provide equivalent
throughput for small data sets).
The lookup function must also be capable of reaching an external daemon
for cache misses (perhaps via a sysfs/udev domain socket?).
The default for the lookup function would be to use a 1:1 mapping (determined
from the exports initialization (xtab, and loaded by mountd when the remote
host does a mount). The lookup function MAY be able to use small lists without
a daemon (say 20-30 uids and gids) and support small exclusion lists (maybe
ranges for both permitted/excluded lists?).
The daemon would then be usefull for large lists to help keep the cache size
down. The size of the cache - containing real entries - should be a
configuration parameter.
There is also a possible issue with interfacing to the LSM, since this
touches on some of the structures that it can/should trace (though this
may be delayed until later for implementation, it is something to think
about for audit and security control).
Unfortunately, I'm not in a position to do coding - I've seen the AT&T System
V code (Cray version about 5 years ago)- to the point of debugging some NFS
mapping failures (which had to to with multi-level security options in
additon to UID/GID mapping).
The NFSv4 client and server already do uid/gid mapping. That is
*mandatory* in the NFSv4 protocol, which dictates that you are only
allowed to send strings of the form user@domain on the wire.
If you really need uid/gid mapping for NFSv2/v3 too, why not just build
on the existing v4 upcall/downcall mechanisms?
Cheers,
Trond
On Mar 10, 2004 15:41 -0600, Jesse Pollard wrote:
> On Wednesday 10 March 2004 11:58, S?ren Hansen wrote:
> > The server can't trust the client as it is now anyway. The client can do
> > whatever it wants already. There is no security impact as I see it.
>
> First, if the server refuses to map uids into what it considers system
> (say, those less than 100... or better, 1000) then the daemons that may be
> using those uids/gids on the server (or other hosts even) will be
> protected from a simple mapping attack. Any attempt to do so will be detected
> by the server, blocked, and reported.
>
> Second, if the various organizations are mapped, then only maps (and
> uids/gids) authorized by those maps can be used. Any hanky panky on the
> client host will ONLY involve those accounts/uids already on the client. They
> will NOT be able to map to accounts/uids that are assigned to the other
> organization. Again, attempts to access improper accounts will be detected
> by the server, blocked, and reported.
I agree with S?ren on this. If the client is compromised such that the
attacker can manipulate the maps (i.e. root) then there is no reason why
the attacker can't just "su" to any UID it wants (regardless of mapping)
and NFS is none-the-wiser.
If the client is trusted to mount NFS, then it is also trusted enough not
to use the wrong UID. There is no "more" or "less" safe in this regard.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
ons, 2004-03-10 kl. 22:41 skrev Jesse Pollard:
> > > > > and unlimited number of groups assigned to a single user?
> > > > No. That's not my problem, is it? I just provide the mapping system.
> > > but the mapping system has to be able to handle it.
> > How do you figure that?
> I should have said "designed to handle it" in a future expansion. I was
> wrong in making 64 bits as important as it looks.
I'm not talking about the 64 bits uid's and gid's. I'm talking about the
mapping system having to handle users' group memberships. Why would it
have to do that?
> > > > The maps are on the client, so that's no issue. The trick is to make it
> > > > totally transparent to the filesystem being mounted, be it networked or
> > > > non-networked.
> > > The server cannot trust the clients to do the right thing.
> > The server can't trust the client as it is now anyway. The client can do
> > whatever it wants already. There is no security impact as I see it.
> Ah - but if the server refuses to map the uid then the server is more
> protected.
Yes. I know. This is not the problem i was trying to fix. This
discussion is going nowhere.
If I redesigned the way house doors worked, you'd be moaning about the
fact that the TV inside the house might be broken or stolen by someone
who enters the house. That's true. It might very well be. The only way
to secure it is to give your key to noone. The second you give you key
to someone else, you're basically fscked. And of course I know this is a
problem. It's a huge problem. I hope someone will fix it some day. It is
not, however, what I'm trying to do here.
--
Salu2, S?ren.
ons, 2004-03-10 kl. 23:45 skrev Trond Myklebust:
> The NFSv4 client and server already do uid/gid mapping. That is
> *mandatory* in the NFSv4 protocol, which dictates that you are only
> allowed to send strings of the form user@domain on the wire.
Clever!
> If you really need uid/gid mapping for NFSv2/v3 too, why not just build
> on the existing v4 upcall/downcall mechanisms?
Because that would require changes to both ends of the wire. I want this
to:
1. Work for ALL filesystems (NFS, smbfs, ext2(*) etc.)
2. Be transparent for the server.
*: For ext2, this could come in handy if you are moving disks between
systems.
--
Salu2, S?ren.
On Wednesday 10 March 2004 17:46, Andreas Dilger wrote:
> On Mar 10, 2004 15:41 -0600, Jesse Pollard wrote:
> > On Wednesday 10 March 2004 11:58, S?ren Hansen wrote:
> > > The server can't trust the client as it is now anyway. The client can
> > > do whatever it wants already. There is no security impact as I see it.
> >
> > First, if the server refuses to map uids into what it considers system
> > (say, those less than 100... or better, 1000) then the daemons that may
> > be using those uids/gids on the server (or other hosts even) will be
> > protected from a simple mapping attack. Any attempt to do so will be
> > detected by the server, blocked, and reported.
> >
> > Second, if the various organizations are mapped, then only maps (and
> > uids/gids) authorized by those maps can be used. Any hanky panky on the
> > client host will ONLY involve those accounts/uids already on the client.
> > They will NOT be able to map to accounts/uids that are assigned to the
> > other organization. Again, attempts to access improper accounts will be
> > detected by the server, blocked, and reported.
>
> I agree with S?ren on this. If the client is compromised such that the
> attacker can manipulate the maps (i.e. root) then there is no reason why
> the attacker can't just "su" to any UID it wants (regardless of mapping)
> and NFS is none-the-wiser.
Absolutely true. The attacker can do the "su" to any uid. Which is why the
server must be the one to provide the mapping service. The server does not
have to accept the UID unless it is one of the entries in the authorized map.
This isolates the penetration to only the accounts authorized to the
penetrated host.
And even root can be blocked from access to the server - in fact, root
could be mapped to any uid by the server (say for the purpose of remote
configuration files). The penetrated client can only access accounts that
were authorized by the server map.
> If the client is trusted to mount NFS, then it is also trusted enough not
> to use the wrong UID. There is no "more" or "less" safe in this regard.
It is only trusted to not misuse the uids that are mapped for that client. If
the client DOES misuse the uids, then only those mapped uids will be affected.
UIDS that are not mapped for that host will be protected.
It is to ISOLATE the penetration to the host that this is done. The server
will not and should not extend trust to any uid not authorized to that host.
This is what the UID/GID maps on the server provide.
On Wednesday 10 March 2004 16:45, Trond Myklebust wrote:
> The NFSv4 client and server already do uid/gid mapping. That is
> *mandatory* in the NFSv4 protocol, which dictates that you are only
> allowed to send strings of the form user@domain on the wire.
>
> If you really need uid/gid mapping for NFSv2/v3 too, why not just build
> on the existing v4 upcall/downcall mechanisms?
Drat... I completely forgot about that. It's been a year since I used NFS
at all.
That would be the best way.
On Thursday 11 March 2004 02:22, S?ren Hansen wrote:
> ons, 2004-03-10 kl. 22:41 skrev Jesse Pollard:
> > > > > > and unlimited number of groups assigned to a single user?
> > > > >
> > > > > No. That's not my problem, is it? I just provide the mapping
> > > > > system.
> > > >
> > > > but the mapping system has to be able to handle it.
> > >
> > > How do you figure that?
> >
> > I should have said "designed to handle it" in a future expansion. I was
> > wrong in making 64 bits as important as it looks.
>
> I'm not talking about the 64 bits uid's and gid's. I'm talking about the
> mapping system having to handle users' group memberships. Why would it
> have to do that?
NFS v2/3 have a limit of gids that can be passed. I know on v2 it is limited
to 16. If the group that is permitted access is not in that list, then file
access will fail, even though the user IS supposed to have access. The list
of groups that is allowed is only the first 16 of a potentially very large
list.
> > > > > The maps are on the client, so that's no issue. The trick is to
> > > > > make it totally transparent to the filesystem being mounted, be it
> > > > > networked or non-networked.
> > > >
> > > > The server cannot trust the clients to do the right thing.
> > >
> > > The server can't trust the client as it is now anyway. The client can
> > > do whatever it wants already. There is no security impact as I see it.
> >
> > Ah - but if the server refuses to map the uid then the server is more
> > protected.
>
> Yes. I know. This is not the problem i was trying to fix. This
> discussion is going nowhere.
> If I redesigned the way house doors worked, you'd be moaning about the
> fact that the TV inside the house might be broken or stolen by someone
> who enters the house. That's true. It might very well be. The only way
> to secure it is to give your key to noone. The second you give you key
> to someone else, you're basically fscked. And of course I know this is a
> problem. It's a huge problem. I hope someone will fix it some day. It is
> not, however, what I'm trying to do here.
Then you don't understand the problem yet. Just because UIDs don't show up
properly on the client is no reason to map them in an insecure manner. And
it has nothing to do with house doors or TV sets.
On Thursday 11 March 2004 02:29, S?ren Hansen wrote:
> ons, 2004-03-10 kl. 23:45 skrev Trond Myklebust:
> > The NFSv4 client and server already do uid/gid mapping. That is
> > *mandatory* in the NFSv4 protocol, which dictates that you are only
> > allowed to send strings of the form user@domain on the wire.
>
> Clever!
>
> > If you really need uid/gid mapping for NFSv2/v3 too, why not just build
> > on the existing v4 upcall/downcall mechanisms?
>
> Because that would require changes to both ends of the wire. I want this
> to:
> 1. Work for ALL filesystems (NFS, smbfs, ext2(*) etc.)
> 2. Be transparent for the server.
It will be a major security vulnerability.
>
> *: For ext2, this could come in handy if you are moving disks between
> systems.
Mapping fails in this case due to UID loops (been there done that too - had to
spend a week changing uids because of it - most were quickly changed because
there was no conflict, but about 100 out of 1000 were in loops. Users had
multiple accounts on both machines, but different uids on each. You can end up
having to map the same uid to two different uids.
tor, 2004-03-11 kl. 15:18 skrev Jesse Pollard:
> >> I should have said "designed to handle it" in a future expansion. I was
> >> wrong in making 64 bits as important as it looks.
> > I'm not talking about the 64 bits uid's and gid's. I'm talking about the
> > mapping system having to handle users' group memberships. Why would it
> > have to do that?
> NFS v2/3 have a limit of gids that can be passed. I know on v2 it is limited
> to 16. If the group that is permitted access is not in that list, then file
> access will fail, even though the user IS supposed to have access. The list
> of groups that is allowed is only the first 16 of a potentially very large
> list.
This is NOT the responsibility of the mapping system! I'm not
implementing a new network file system. All I do, is supply a system
that tells the client that what the server refers to as gid 26 is gid
523 locally. Who is a member and who is not is irrelevant!
> > Yes. I know. This is not the problem i was trying to fix. This
> > discussion is going nowhere.
> > If I redesigned the way house doors worked, you'd be moaning about the
> > fact that the TV inside the house might be broken or stolen by someone
> > who enters the house. That's true. It might very well be. The only way
> > to secure it is to give your key to noone. The second you give you key
> > to someone else, you're basically fscked. And of course I know this is a
> > problem. It's a huge problem. I hope someone will fix it some day. It is
> > not, however, what I'm trying to do here.
> Then you don't understand the problem yet.
That's funny. I thought it was the privilege of the designer to decide
what he has tried to design. When did this change?
I'll repeat it just one more time:
Imagine two systems with all the same users on them. The users however
have different uid's on the two systems. This fscks up the ownerships. I
fix this by translating the uid's before they hit the wire. Well,
actually before they hit the nfs layer. Behold! All is well, and all
users have access to their own files.
> Just because UIDs don't show up properly on the client is no reason to
> map them in an insecure manner.
Let's just for a second assume that I'm the slow one here. Why is the
world a less secure place after this system is incorporated into the
kernel?
> And it has nothing to do with house doors or TV sets.
Really? Dang, I need rewrite the entire thing now! (I BTW still reserve
the right to be sarcastic and to make other good analogies).
--
Salu2, S?ren.
tor, 2004-03-11 kl. 15:31 skrev Jesse Pollard:
> > Because that would require changes to both ends of the wire. I
> > want this to:
> > 1. Work for ALL filesystems (NFS, smbfs, ext2(*) etc.)
> > 2. Be transparent for the server.
> It will be a major security vulnerability.
Well, I COULD repeat myself over and over again....
Short answer:
No.
Long answer:
Nooo.
> > *: For ext2, this could come in handy if you are moving disks between
> > systems.
> Mapping fails in this case due to UID loops (been there done that too
You haven't seen a line of code I've written for this yet, and already
you're telling me that I implemented it the wrong way because that's
what you did when you once tried?
I BTW also fail to see why it all of the sudden is my problem that
people have more than one user on the same system. (Hint: it isn't)
--
Salu2, S?ren.
On Thu, Mar 11, 2004 at 09:29:17AM +0100, S?ren Hansen wrote:
> ons, 2004-03-10 kl. 23:45 skrev Trond Myklebust:
> > If you really need uid/gid mapping for NFSv2/v3 too, why not just build
> > on the existing v4 upcall/downcall mechanisms?
>
> Because that would require changes to both ends of the wire. I want this
> to:
> 1. Work for ALL filesystems (NFS, smbfs, ext2(*) etc.)
> 2. Be transparent for the server.
The latter at least you could already do; just modify the v4
upcall and downcall to map between uid's and uid's instead of mapping
between uid's and names.
--Bruce Fields
On Thu, Mar 11, 2004 at 08:08:31AM -0600, Jesse Pollard wrote:
> On Wednesday 10 March 2004 17:46, Andreas Dilger wrote:
> > If the client is trusted to mount NFS, then it is also trusted enough not
> > to use the wrong UID. There is no "more" or "less" safe in this regard.
>
> It is only trusted to not misuse the uids that are mapped for that client. If
> the client DOES misuse the uids, then only those mapped uids will be affected.
> UIDS that are not mapped for that host will be protected.
>
> It is to ISOLATE the penetration to the host that this is done. The server
> will not and should not extend trust to any uid not authorized to that host.
> This is what the UID/GID maps on the server provide.
You're making an argument that uid mapping on the server could be used
to provide additional security; I agree.
I don't believe you can argue, however, that providing uid mapping on
the client would *decrease* security, unless you believe that mapping
uid's on the client precludes also mapping uid's on the server.
--Bruce Fields
Jesse Pollard <[email protected]> writes:
>
> Absolutely true. The attacker can do the "su" to any uid. Which is
> why the server must be the one to provide the mapping service. The
> server does not have to accept the UID unless it is one of the
> entries in the authorized map.
Here's a simple, typical problem:
I want to connect a Linux laptop to a network with existing NFS/NIS
infrastructure in place and mount and use, say, an NFS home directory.
Unfortunately, the UID mappings differ between the existing
infrastructure and my laptop. For example, all the files in my NFS
directory are all owned by uid=45067 gid=102, but my user and default
group on the laptop are 1000 and 1000 respectively.
I don't adminsiter the NFS server; I can't ask the administrator to
set up a server-side mapping system just for my benefit. But, I *can*
convince the administrator to add:
/home/b/u/buhr mymachine(squash_uids=0-45066,45068-65535,squash_gids=0-100)
to his exports file.
Now, I can mount this filesystem on my machine. Trouble is, I can't
read or write any of my files.
Now, I could edit my local "passwd" and "group" files, change the
ownership of the files in my local home directory, and everything
would work smashingly. Or, I could use S?ren's patch with a mapping
file and a mount option to achieve a similar effect with much less
work and disturbance.
Bottom line: S?ren's patch would be very useful in a number of
real-world situations, and it can't *possibly* have an signficant
adverse effect on security because any attacker able to modify the
client-side mappings could, in principle, modify "passwd" and "group"
or write and install a similar kernel patch on the client anyway.
--
Kevin <[email protected]>
P? to , 11/03/2004 klokka 03:29, skreiv S?ren Hansen:
> > If you really need uid/gid mapping for NFSv2/v3 too, why not just build
> > on the existing v4 upcall/downcall mechanisms?
>
> Because that would require changes to both ends of the wire. I want this
> to:
> 1. Work for ALL filesystems (NFS, smbfs, ext2(*) etc.)
> 2. Be transparent for the server.
No... I said to build on the upcall/downcall mechanism. I said nothing
about modifying the on-the-wire protocol.
My point is that we have evolved more or less GENERIC mechanisms for
calling up to userland with a string/number and having it mapped into
something else via a downcall. (worse: in fact we have 2 mechanisms for
doing it - one that is used by the client, the other by the server).
The only way in which we fail to meet the above requirements are that
the code to do it is in the NFS/RPC layers. Move it out of there, and it
could be reused by everybody.
No need for a third upcall/downcall mechanism that does the same thing.
Cheers,
Trond
Kevin Buhr wrote:
> Now, I can mount this filesystem on my machine. Trouble is, I can't
> read or write any of my files.
>
> Now, I could edit my local "passwd" and "group" files, change the
> ownership of the files in my local home directory, and everything
> would work smashingly.
Been there, done that. Changed entire home network each time job
changed, so that laptop could play well with work and home machines
It doesn't work as soon as you connect your laptop to different
locations that have different uid mappings - either at different
times, or simultaneously.
I've had desktop machines that had to be simultaneously connected to
servers in different administrative domains to do their daily work.
Naturally group had their own set of users and ids - I just happened
to have an account on each. It was a pain.
> Bottom line: S?ren's patch would be very useful in a number of
> real-world situations.
I agree. If there's a universal way to hook the mapping to an LDAP or
NIS, so that each mounted server could be accessed using the uid/gid
mappings based on the LDAP/NIS service for that server's
administrative domain, that'd be nice.
Using the NFSv4 upcalls seems like a good way to go about it, and give
uniform results over all the different filesystems including NFS. Not
that I've looked at any of that code.
-- JAmie
tor, 2004-03-11 kl. 20:41 skrev Trond Myklebust:
> > > If you really need uid/gid mapping for NFSv2/v3 too, why not just build
> > > on the existing v4 upcall/downcall mechanisms?
> > Because that would require changes to both ends of the wire. I want this
> > to:
> > 1. Work for ALL filesystems (NFS, smbfs, ext2(*) etc.)
> > 2. Be transparent for the server.
> No... I said to build on the upcall/downcall mechanism. I said nothing
> about modifying the on-the-wire protocol.
Oh, ok. I just haven't understood the NFSv4 up/down calls, then. There's
a userspace daemon listening for requests to map ID's and such? Does it
map usernames to uid'ss or uid's to uid's? Does it require the usernames
to be the same on the client and the server?
> The only way in which we fail to meet the above requirements are that
> the code to do it is in the NFS/RPC layers. Move it out of there, and it
> could be reused by everybody.
> No need for a third upcall/downcall mechanism that does the same thing.
That makes sense. I'll have to take a look at the nfs code before I do
anything else, though.
--
Salu2, S?ren.
On Thursday 11 March 2004 08:39, S?ren Hansen wrote:
> tor, 2004-03-11 kl. 15:18 skrev Jesse Pollard:
> > > Yes. I know. This is not the problem i was trying to fix. This
> > > discussion is going nowhere.
> > > If I redesigned the way house doors worked, you'd be moaning about the
> > > fact that the TV inside the house might be broken or stolen by someone
> > > who enters the house. That's true. It might very well be. The only way
> > > to secure it is to give your key to noone. The second you give you key
> > > to someone else, you're basically fscked. And of course I know this is
> > > a problem. It's a huge problem. I hope someone will fix it some day. It
> > > is not, however, what I'm trying to do here.
> >
> > Then you don't understand the problem yet.
>
> That's funny. I thought it was the privilege of the designer to decide
> what he has tried to design. When did this change?
>
> I'll repeat it just one more time:
> Imagine two systems with all the same users on them. The users however
> have different uid's on the two systems. This fscks up the ownerships. I
> fix this by translating the uid's before they hit the wire. Well,
> actually before they hit the nfs layer. Behold! All is well, and all
> users have access to their own files.
As long as it is done on the server, there is no problem.
> > Just because UIDs don't show up properly on the client is no reason to
> > map them in an insecure manner.
>
> Let's just for a second assume that I'm the slow one here. Why is the
> world a less secure place after this system is incorporated into the
> kernel?
Because a rogue client will have access to every uid on the server.
Mapping provides a shield to protect the server.
If mapping is going to be done, then it must be done on the server.
Mapping is only usefull when you are crossing security domains. It is
less than usefull within one security domain since that confuses the
issue of access rights and identity.
On Thursday 11 March 2004 10:02, J. Bruce Fields wrote:
> On Thu, Mar 11, 2004 at 08:08:31AM -0600, Jesse Pollard wrote:
> > On Wednesday 10 March 2004 17:46, Andreas Dilger wrote:
> > > If the client is trusted to mount NFS, then it is also trusted enough
> > > not to use the wrong UID. There is no "more" or "less" safe in this
> > > regard.
> >
> > It is only trusted to not misuse the uids that are mapped for that
> > client. If the client DOES misuse the uids, then only those mapped uids
> > will be affected. UIDS that are not mapped for that host will be
> > protected.
> >
> > It is to ISOLATE the penetration to the host that this is done. The
> > server will not and should not extend trust to any uid not authorized to
> > that host. This is what the UID/GID maps on the server provide.
>
> You're making an argument that uid mapping on the server could be used
> to provide additional security; I agree.
>
> I don't believe you can argue, however, that providing uid mapping on
> the client would *decrease* security, unless you believe that mapping
> uid's on the client precludes also mapping uid's on the server.
Not really - it would be a 1:1 map... so what would be the purpose?
The problem is in the audit - the server would report a violation in
uid xxx. Which according to it's records is not used on the penetrated client
(at least not via the filesystem). Yet the administrator would report that the
uid is valid (because of a bogus local map).
Double mapping also doubles the audit complications :-)
fre, 2004-03-12 kl. 14:52 skrev Jesse Pollard:
> > Let's just for a second assume that I'm the slow one here. Why is the
> > world a less secure place after this system is incorporated into the
> > kernel?
> Because a rogue client will have access to every uid on the server.
As opposed to now when a rogue client is very well contained?
> Mapping provides a shield to protect the server.
A mapping system could provide extra security if implemented on the
server. That's true. This is, however, not what I'm trying to do. This
system is NOT a security related one (it doesn't increase nor decrease
security), but rather a convenience related one.
--
Salu2, S?ren.
Hi!
> Here's a simple, typical problem:
>
> I want to connect a Linux laptop to a network with existing NFS/NIS
> infrastructure in place and mount and use, say, an NFS home directory.
> Unfortunately, the UID mappings differ between the existing
> infrastructure and my laptop. For example, all the files in my NFS
> directory are all owned by uid=45067 gid=102, but my user and default
> group on the laptop are 1000 and 1000 respectively.
>
> I don't adminsiter the NFS server; I can't ask the administrator to
> set up a server-side mapping system just for my benefit. But, I *can*
> convince the administrator to add:
>
> /home/b/u/buhr mymachine(squash_uids=0-45066,45068-65535,squash_gids=0-100)
>
> to his exports file.
Well... teach nfsd to accept
...squash_uids=...,map_uid=10000:45067,...
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
On Fri, Mar 12, 2004 at 07:58:33AM -0600, Jesse Pollard wrote:
> Not really - it would be a 1:1 map... so what would be the purpose?
Are you asking what would be the purpose of client-side mapping?
So, in the worst case you have a laptop that you want to be able to
simultaneously mount one NFS server maintained by organization X, and
another maintained by organization Y. But unfortunately you have
different uid's in X and Y. (Given sufficiently large independent
organizations X and Y this is inevitable and unfixable.) What do you
do?
> The problem is in the audit - the server would report a violation in
> uid xxx. Which according to it's records is not used on the penetrated client
> (at least not via the filesystem). Yet the administrator would report that the
> uid is valid (because of a bogus local map).
I don't understand your description of the problem; could you be more
specific? E.g., what do you mean by "a violation in uid xxx"?
In general if your server trusts clients to get uid's right, and if
users already have sufficient control over the client to tell the kernel
to remap uid's, then they can already lie to the server about their uid.
(It probably happens every now and then already just by mistake; e.g. if
people are throwing a linux distribution on their personal laptop and
expecting to be able to mount the nfsd server there's a good chance
they'll forget to give themselves the right uid from the start.)
--Bruce Fields
On Friday 12 March 2004 09:00, S?ren Hansen wrote:
> fre, 2004-03-12 kl. 14:52 skrev Jesse Pollard:
> > > Let's just for a second assume that I'm the slow one here. Why is the
> > > world a less secure place after this system is incorporated into the
> > > kernel?
> >
> > Because a rogue client will have access to every uid on the server.
>
> As opposed to now when a rogue client is very well contained?
>
> > Mapping provides a shield to protect the server.
>
> A mapping system could provide extra security if implemented on the
> server. That's true. This is, however, not what I'm trying to do. This
> system is NOT a security related one (it doesn't increase nor decrease
> security), but rather a convenience related one.
Then it becomes an identity mapping (as in 1:1) and is therefore
not usefull.
If you are doing double mapping, then I (as a server administrator)
would not export the filesystem to you.
The current situation is always a 1:1 mapping (NFS version < 4). Therefore
any filesystem export is by definition within the same security domain.
If you as an administrator of a client host violate the UIDs assigned to
you (by hiding the audit trail), then you are violating the rules established
in that security domain; and should not be trusted - and the client host
should not have an available export.
It is never necessary to map on a client. It means that the server has been
improperly setup, or that the client is not within the proper security domain.
On Friday 12 March 2004 14:08, J. Bruce Fields wrote:
> On Fri, Mar 12, 2004 at 07:58:33AM -0600, Jesse Pollard wrote:
> > Not really - it would be a 1:1 map... so what would be the purpose?
>
> Are you asking what would be the purpose of client-side mapping?
>
> So, in the worst case you have a laptop that you want to be able to
> simultaneously mount one NFS server maintained by organization X, and
> another maintained by organization Y. But unfortunately you have
> different uid's in X and Y. (Given sufficiently large independent
> organizations X and Y this is inevitable and unfixable.) What do you
> do?
The server maps the valid uid to the uid used on the client.
Obviously the client is not under the control of the server security domain.
> > The problem is in the audit - the server would report a violation in
> > uid xxx. Which according to it's records is not used on the penetrated
> > client (at least not via the filesystem). Yet the administrator would
> > report that the uid is valid (because of a bogus local map).
>
> I don't understand your description of the problem; could you be more
> specific? E.g., what do you mean by "a violation in uid xxx"?
>
> In general if your server trusts clients to get uid's right, and if
> users already have sufficient control over the client to tell the kernel
> to remap uid's, then they can already lie to the server about their uid.
> (It probably happens every now and then already just by mistake; e.g. if
> people are throwing a linux distribution on their personal laptop and
> expecting to be able to mount the nfsd server there's a good chance
> they'll forget to give themselves the right uid from the start.)
1. your first assumpion: "if your server trusts clients". The server
should NOT trust a remote client.
2. "then they can already lie to the server about their uid" means the client
is NOT under control and again should not be trusted.
On Mar 11, 2004 08:08 -0600, Jesse Pollard wrote:
> On Wednesday 10 March 2004 17:46, Andreas Dilger wrote:
> > I agree with S?ren on this. If the client is compromised such that the
> > attacker can manipulate the maps (i.e. root) then there is no reason why
> > the attacker can't just "su" to any UID it wants (regardless of mapping)
> > and NFS is none-the-wiser.
>
> Absolutely true. The attacker can do the "su" to any uid. Which is why the
> server must be the one to provide the mapping service. The server does not
> have to accept the UID unless it is one of the entries in the authorized map.
But this is true whether the client is mapping the UIDs or not. The server
wouldn't know whether the client is mapping UIDs or not, so it shouldn't trust
UIDs from a client that isn't supposed to be using that UID.
> This isolates the penetration to only the accounts authorized to the
> penetrated host.
Still true regardless of client-side UID mapping.
> And even root can be blocked from access to the server - in fact, root
> could be mapped to any uid by the server (say for the purpose of remote
> configuration files). The penetrated client can only access accounts that
> were authorized by the server map.
Still true regardless of client-side UID mapping.
> > If the client is trusted to mount NFS, then it is also trusted enough not
> > to use the wrong UID. There is no "more" or "less" safe in this regard.
>
> It is only trusted to not misuse the uids that are mapped for that client. If
> the client DOES misuse the uids, then only those mapped uids will be affected.
> UIDS that are not mapped for that host will be protected.
Still true regardless of client-side UID mapping.
> It is to ISOLATE the penetration to the host that this is done. The server
> will not and should not extend trust to any uid not authorized to that host.
Still true regardless of client-side UID mapping.
Maybe you are confusing some term "mapping" that you understand for the
server-side (related to allowing only certain UIDs for a particular host?)
with an unrelated operation of the same name that S?ren is proposing
(which is just a simple uid->uid translation)?
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
man, 2004-03-15 kl. 18:05 skrev Jesse Pollard:
> > > Because a rogue client will have access to every uid on the server.
> > As opposed to now when a rogue client is very well contained?
You didn't answer this.
> > > Mapping provides a shield to protect the server.
> > A mapping system could provide extra security if implemented on the
> > server. That's true. This is, however, not what I'm trying to do. This
> > system is NOT a security related one (it doesn't increase nor decrease
> > security), but rather a convenience related one.
> Then it becomes an identity mapping (as in 1:1) and is therefore
> not usefull.
If you don't find it useful, don't use it.
> If you are doing double mapping, then I (as a server administrator)
> would not export the filesystem to you.
Whereas now all clients are trustworthy?
> The current situation is always a 1:1 mapping (NFS version < 4).
Didn't you just say 1:1 mapping isn't useful?
> If you as an administrator of a client host violate the UIDs assigned to
> you (by hiding the audit trail), then you are violating the rules established
> in that security domain; and should not be trusted - and the client host
> should not have an available export.
Exporting filesystems via NFS is always insecure. This system just makes
it more convenient for the client. The very picosecond you decide to
allow e.g. the entire LAN to mount your filesystems you've thrown
security out the window.
What do you propose I do, if my company e.g. is running Solaris on the
servers and I want to mount something from one of the servers on my
laptop? I can't go and demand them to make changes to their Solaris nfs
implementations (well, I COULD, but I COULD also hammer nails through my
toes. Neither will make a difference). If I just mount the filesystem,
the ID's a bound to be messed up unless the user and group database on
my laptop is EXACTLY the same as on the server. News flash: They aren't.
And I KNOW that I'm far from alone with this problem. That do you
propose I do then?
And what about this:
The server's user database uses UID's 1000 and up for regular users. If
I create 2000 users on my laptop with uid's 1000-2999 and mount the
filesystem from the server? I can just log in with each of these users
and access the files of the user on the server with the same UID as my
local user. See? No mapping involved and yet I have access to everything
I want. So, you can't trust nfs clients now either! So what's the big
deal if I make it more convenient to use it by implementing a mapping
system that maps my local uid to my uid on the server?
--
Salu2, S?ren.