Messages in this thread | | | Date | Mon, 27 Sep 1999 08:52:25 -0500 (CDT) | From | Jesse Pollard <> | Subject | Re: Ext3 filesystem info? |
| |
> From: Konrad Rosenbaum <htw6966@htw-dresden.de> > > > > Seems to me that some of this can be solved with a good generic > > > ACL interface in the VFS. Various filesystems may then implement > > > more or less of the VFS interface depending on what they support. > > > Just as some filesystems implement links and some don't. > > > > ACLs are just far too varied to be combined effectively in a single > > API. We support distributed filesystems like AFS in which the server's > > notion of who a user is is completely foreign to the kernel's uid/gid > > scheme: how do you propose to identify such users when manipulating AFS > > ACLs? > > I know I'm dumb, but what does really vary? The semantics or the rights > you may grant/revoke in the ACL? If it is "only" the semantic design and > implementation shouldn't be difficult.
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/
| |