> The 'struct file' is allocated when the file is opened, so it is not
> shared among users. Each user will therefore be able to cache his/her
> own permissions. This is why I want to pass the file structure rather
> than the 'dentry' structure to the readpage/writepage. The latter is
> common to all users of the file, and can therefore not be used to pass
> user/process-specific information.
Proof ad absurdum: if two users write to one page, whose
credentials will you use?
The problem does not exist for AUTH_SYS (i.e. for really needed
situation) at all. Just use any credentials, even credentials
of file owner rather than person opened file.
With true auth. flavors you will have worse problems.
F.e. if file, opened by one user, is read/written by another user,
you cannot use auth. token of the first user. It is basic
violation of security rules, host cannot cheat anyone with forged
credentials. So that, leave the problem for future, synchronous
writes are more than enough for this case.
Instead of dreaming about kerberi, it would be better to clean mud from
nfs and sunrpc and make it working for begginning. I understand
it is boring and not sexy work, but yet... someone has to make this...
F.e. the first look showed:
1.
void rpciod_tcp_dispatcher(void)
{
start_bh_atomic();
do_rpciod_tcp_dispatcher();
end_bh_atomic();
}
It is immediate death. Think why.
2.
static inline struct rpc_rqst *
xprt_lookup_rqst(struct rpc_xprt *xprt, u32 xid)
{
struct rpc_task *head, *task;
struct rpc_rqst *req;
unsigned long oldflags;
int safe = 0;
spin_lock_irqsave(&rpc_queue_lock, oldflags);
Lock does nothing useful. Think why.
3.
static int
xprt_down_transmit(struct rpc_task *task)
{
struct rpc_xprt *xprt = task->tk_rqstp->rq_xprt;
struct rpc_rqst *req = task->tk_rqstp;
start_bh_atomic();
spin_lock(&xprt_lock);
Not commented. Think why.
Alexey
-
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/