Re: [PATCH] new syscall: flink

["Clayton Weaver" <cgweav@email.com>]

Do file access capabilities (and ACLs where those
are enabled)attach to the directory entry or the inode for a file? 

I remember Linus wishing that capabilities
on files could have different multiple concurrent values in different directory entry contexts.
Seems like the kernel would need to be able
to trump these "capability views", which
would need to be associated with directory
entries, based on data stored with the inode
(so that you can drop capabilities when creating
a link but you can't elevate them).

(Someone already mentioned in this thread that traditional unix permissions are stored in the inode.)

The restricted directories with loose permissions
on the files within them looks more like an
application programmer issue than a kernel issue to me. The parent or server could always chmod the file(or copy it to a read-only file and open that) before execing or passing the open fd.

So who owns the inode? Or does "owned by
uid #N" only make sense in the context of a
directory entry? If so, does ownership of the linked-to fd propagate to the new directory
entry from the old directory entry? What if it
had been unlinked before the flink()?

Seems like the ultimate security constraints on files have to be stored in the inode or your security is potentially hosed merely by the ability to create a new directory entry for the same inode from a different uid (whether it
needs to do it in a different directory is a
separate issue). 
 
Regards,

Clayton Weaver
<mailto: cgweav@email.com>

-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup