It's better security - only the kernel validates access. What you are asking
for is to allow a daemon (granted, it is privileged) to take over part of the
security function. This dilutes the validity of the security implementation
since more tests must be implemented, in two or more (potentially one for each
network file service), making it more difficult to determine correctness.
>
>Daemons like Samba now need to fork(), and change owner
>to tested permissions. It seems more reasonable to
>allow root to test permissions via a system call.
NFS doesn't have that need - the specific server process just changes its
own effective UID, then switches back afterward. I think (not sure) that
if samba had multiple threads then a thread could change it's effective
UID for the test, and switch back afterward. The major performance penalty
for NFS here is the contention on the single service port (all processes
attempt to get a request, only one gets it).
Another reason for daemons to change effective UID occurs when system
accounting (bean counting) is used. The penalty for the resource overhead is
charged back to the user making the access.
This is not to say that there can't be a better way to solve this, just that
this is the "traditional" solution to supporting file access for remote
clients.
One optimization I did see for NFS involved a "open file by inode number"
system call. This one still used all the accounting/UID changes and stuff,
but it eliminated the namei search from opening a file. Frequently in NFS
what occured was a "stat" call. This information was entered into the NFS
cache structure. If an "open" came for the same file (as matched in the cache)
then the open inode would be used instead of a full path open. This had
a large tendency to eliminate the duplication of the inode search through
one or more filesystems (through the directory search). The security weakness
in this (depending on point of view) is that a file could not be protected
by just making its parent directory inaccessable. Inode numbers could be
guessed, and made random inode numbers/versions more important. Even there,
the only thing that would guarantee protection is the proper protection
applied to the file, not just the directory the file is in.
>I have heard that this question has been asked in the past,
>with no response.
Sorry - I missed the question.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/