lkml.org 
[lkml]   [2002]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] Initial support for struct vfs_cred [0/1]
From
On Mon, Sep 09, 2002 at 12:04:03AM +0200, Luca Barbieri wrote:
> > Now if this is a multithreaded application that does this in one thread
> > and another thread happens to open a completely unrelated file around
> > the time that the first thread drops this application's setuid
> > permissions. If we don't use a copy during the open upcall, but copy it
> > after the fact, we don't have the correct permissions around the time
> > the file is closed.
> You would copy them during the filesystem open.
> My point was that in the generic vfs open there is no need to use copied
> credentials so credentials copying can be restricted to network
> filesystems with not-very-good designs.
>
> > > BTW, imho a correctly designed network filesystem should have a single
> > > stateful encrypted connection (or a pool of equally authenticated ones)
> > > and credentials (i.e. passwords) should only be passed when the user
> > > makes the first filesystem access. After that the server should do
> > > authentication with the OR of all credentials received and the client
> > > kernel should further decide whether it can give access to a particular
> > > user.
> >
> > Right, which is pretty close to what Coda does.
> This is in contradiction with your statement about credentials sent
> during close.

How so, Coda has a pool of authenticated connections per user. But the
userspace cachemanager still needs to know which user performed the
operation in order to pick the right connection to send the message.

If user A opens a file and then user B writes/closes it, should it send
the write/close message over the authenticated connection of user B?
Ofcourse not, so we need to store the credentials of the opener with the
file.

This behaviour is the same for any filesystem that performs/requires
additional permission checking after a file is opened, i.e. probably all
network filesystems.

> The advantage of the model I described is that, with the exception of
> connection management, it works exactly like a normal filesystem with
> the exception of some totally inaccessible files due to server access
> denies.

Filedescriptors being used by processes with different user credentials
compared to the opener are more common than you might think. One common
example is stdout/stderr redirection with setuid apps in a shellscript,
another is due to fd passing through Unix domain sockets, or apps that
open files and then drop their priveledges. And it happens even more
with network sockets and pipes, although those possibly don't affect the
VFS (haven't checked if they use generic VFS paths, pipes probably do,
network sockets might).

Jan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.079 / U:1.796 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site