The list of access rights vary depending on the implementation: you may
be able to access a file, but not create it (access to directory), you may
have write access, but not delete - both depend on some form of directory
write: but the host file system may not have W as a permission to a directory.
(this is NOT a unix filesystem being accessed over a net...)
> Could someone just list the types of ACL's spread around here _with_ the
> kind of files they allow ACL's on and the right's they allow to set?linux-kernel@vger.rutgers.edu
>
> Yet I only know NT ACL's (sorry, I haven't worked with real OS'es which
> implement ACL's yet). They just seem to be a list of
> user/group-plus_minus_access-pairs, so I could imagine a quite simple
> ioctl-like syscall for that (it just returns ENOSYS for non-supported
> actions), please look at it before complaining :-)
It can't depend on an IOCTL type interface - you may not be able to open
the file but may be able to read the access list.
> int sys_acl(fd_t fdint mode,...);
>
> where mode may be:
> ACL_LOCK makes write-to-acl-actions atomar (only owner and
> root may use it)
> addition Parameter: ACL_READ, ACL_WRITE, ACL_UNLOCK
> ACL_ACTIVATE additional Parameter: boolean to activate or deactivate
> the ACL of this file/directory
> ACL_GET additional Parameter: number of acl-entry or -1 to return
> amount of entries; pointer to a struct s_acl
> ACL_SET add.Param.: number of the entry and a struct s_acl
> ACL_ADD returns new number
> ACL_DELETE add.Param: number of the entry to be deleted
> ACL_MOVE add.Param: number of ACL to move, position to move to OR:
> ACL_XCHG Params as above, but exchanges these two
>
> struct s_acl{
> int type;/*ACL_USER/ACL_GROUP | ACL_GRANT/ACL_REVOKE*/
> int ugid;/*UID or GID according to type*/
> int access;/*access bits: RWX (for some FS'es Append and others)*/
> };
>
> Ok, now the task for everybody who _really_ knows ACL-systems: which FS'es
> could _not_ be covered by this syscall and why? What to extend to satisfy
> this other FS?
NTFS - UUID references are 128 bits, access rights can be much larger than
RWX (It appears to be a more generic attribute storage that happens to
contain ACLs proper - this is from cursory investigation (some of
them use symbolic names for rights not directly related to access, I
could be wrong... details at 11?:).
DCE - user reference is a symbolic name, not a uid (at least it was the
last time I had the DCE class.
There can be access control lists that control access to applications. The
internal structure of these lists are drastically different from the simple
case of file access (kerberos ACLs for instance).
Kerberos (yes they are ACLs, just interpreted differently)
AFS/Coda (don't know - haven't had access to these)
Also, some ACLs can cascade - It is usually better to replace the entire
list in one atomic operation, otherwise - editing an ACL becomes very difficult
to do correctly.
> IMHO as far as we have a syscall which satisfies almost all FS'es the
> other API's spread around the systems could be emulated in glibc (as with
> fork and clone).
what system call? As far as I have seen, it doesn't esist (yet).
What I had envisioned is:
1. Limits
a. Several different classes of acl:
1. AFS/Coda/DFS
a. ACLs on directories only
b. Network distributed
c. Enforced on server
2. POSIX
a. ACLs on directories and files
b. local to host
c. enforced on host - may or may not be passed to remote server
(as in NFS - that requires changes to NFS protocol)
b. Different Semantics - its almost as if ACLs as a title are describing
different facilities.
2. Initial focus should be on POSIX ACLs, but care to be taken
to prevent excluding others:
a. impose the minimum of policy as possible
b. provide generic facilities where ever possible
1. Just as the "fsck" utility selects the appropriate repair
utility by inspecting the filesystem, the ACL edit should
select the appropriate ACL edit for the given filesystem.
2. The kernel should provide a data path from the filesystem
to the edit facliity
3. The kernel should not impose an interpretation on the data
provided by the edit capability - that will be the job of
the filesystem layer.
c. To allow for efficient implementation:
1. The entire ACL should be transfered to/from the file system
in one block. Individual ACL entry modifications would make
the file system implementation too large and slow.
2. A variable sized ACL implementation can be supported by using
the filesystem type to inform the user of the given limits.
3. Initial Proposal:
a. Semantic interpretation of the given ACL will be up to the
existing VFS permissions function.
b. A minimum of one additional VFS function in the
inode_operations structure (alternatively there could be one
for each of the ACL operations; I view this as supporting only one
new system call):
return_status = acl_access(inode,operation,buffer,length)
where:
inode - the inode being queried
operation - the ACL action to take
buffer - ACL data transfer buffer
length - length of the buffer (bytes)
return_status - error number:
ENOSYS - ACL not implemented
EINVAL - ACL larger than buffer
(get)
input ACL too large (put)
Note: It is not necessary to open the file before accessing the
ACL (use a pathname specification). This is undesirable since
some ACL structures can only be applied to directories.
The operations that can be carried out are:
status - fill the data buffer with:
return file system type
size of single ACL entry (in bytes)?
length of ACL (0 => no ACL)
maximum size of ACL
get ACL - fill buffer with:
file system type
length of ACL (0 => no ACL)
contents of ACL
put ACL - replace the current ACL with the data in the buffer
file system type
length of ACL (0 => delete ACL)
contents of ACL
I view the "length of ACL" to be the bytelength of the entire list
and can be used to create a buffer large enough to hold the ACL.
Note: the get/put operations should be atomic if implemented locally.
Network synchronization is always a coin toss.
c. library manipulation functions (application level access):
acl_get - get acl list into memory
acl_first - return pointer to first acl entry
acl_next - return pointer to next acl (null => end of list)
acl_add - insert ACL at current pointer position (null current
pointer means add to the end of the list)
acl_del - remove ACL at current pointer position.
acl_put - replace the active acl with the updated list. If list
not modified then do nothing.
Note: the acl library functions will have to be fairly intelligent
to be able to parse the various ACL definitions. I don't know
a set of parameters yet.
4. Auditing (this is preliminary rabble-rousing stuff:)
a. Each file system will have to use a centralized audit log function.
The Audit log should contain (even if not done directly by the
file system code. Data from the file system will be merged with
a base record):
base record:
time stamp
host
user
I/O record:
function (all I/O requests)
log information (data reference if any)
status (returned status code)
-------------------------------------------------------------------------
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/