1 /* $NetBSD: fsaccess.h,v 1.4 2014/12/10 04:38:00 christos Exp $ */ 2 3 /* 4 * Copyright (C) 2004-2007, 2009 Internet Systems Consortium, Inc. ("ISC") 5 * Copyright (C) 2000, 2001 Internet Software Consortium. 6 * 7 * Permission to use, copy, modify, and/or distribute this software for any 8 * purpose with or without fee is hereby granted, provided that the above 9 * copyright notice and this permission notice appear in all copies. 10 * 11 * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH 12 * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY 13 * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, 14 * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM 15 * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE 16 * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR 17 * PERFORMANCE OF THIS SOFTWARE. 18 */ 19 20 /* Id: fsaccess.h,v 1.16 2009/01/17 23:47:43 tbox Exp */ 21 22 #ifndef ISC_FSACCESS_H 23 #define ISC_FSACCESS_H 1 24 25 /*! \file isc/fsaccess.h 26 * \brief The ISC filesystem access module encapsulates the setting of file 27 * and directory access permissions into one API that is meant to be 28 * portable to multiple operating systems. 29 * 30 * The two primary operating system flavors that are initially accommodated 31 * are POSIX and Windows NT 4.0 and later. The Windows NT access model is 32 * considerable more flexible than POSIX's model (as much as I am loathe to 33 * admit it), and so the ISC API has a higher degree of complexity than would 34 * be needed to simply address POSIX's needs. 35 * 36 * The full breadth of NT's flexibility is not available either, for the 37 * present time. Much of it is to provide compatibility with what Unix 38 * programmers are expecting. This is also due to not yet really needing all 39 * of the functionality of an NT system (or, for that matter, a POSIX system) 40 * in BIND9, and so resolving how to handle the various incompatibilities has 41 * been a purely theoretical exercise with no operational experience to 42 * indicate how flawed the thinking may be. 43 * 44 * Some of the more notable dumbing down of NT for this API includes: 45 * 46 *\li Each of FILE_READ_DATA and FILE_READ_EA are set with #ISC_FSACCESS_READ. 47 * 48 * \li All of FILE_WRITE_DATA, FILE_WRITE_EA and FILE_APPEND_DATA are 49 * set with #ISC_FSACCESS_WRITE. FILE_WRITE_ATTRIBUTES is not set 50 * so as to be consistent with Unix, where only the owner of the file 51 * or the superuser can change the attributes/mode of a file. 52 * 53 * \li Both of FILE_ADD_FILE and FILE_ADD_SUBDIRECTORY are set with 54 * #ISC_FSACCESS_CREATECHILD. This is similar to setting the WRITE 55 * permission on a Unix directory. 56 * 57 * \li SYNCHRONIZE is always set for files and directories, unless someone 58 * can give me a reason why this is a bad idea. 59 * 60 * \li READ_CONTROL and FILE_READ_ATTRIBUTES are always set; this is 61 * consistent with Unix, where any file or directory can be stat()'d 62 * unless the directory path disallows complete access somewhere along 63 * the way. 64 * 65 * \li WRITE_DAC is only set for the owner. This too is consistent with 66 * Unix, and is tighter security than allowing anyone else to be 67 * able to set permissions. 68 * 69 * \li DELETE is only set for the owner. On Unix the ability to delete 70 * a file is controlled by the directory permissions, but it isn't 71 * currently clear to me what happens on NT if the directory has 72 * FILE_DELETE_CHILD set but a file within it does not have DELETE 73 * set. Always setting DELETE on the file/directory for the owner 74 * gives maximum flexibility to the owner without exposing the 75 * file to deletion by others. 76 * 77 * \li WRITE_OWNER is never set. This too is consistent with Unix, 78 * and is also tighter security than allowing anyone to change the 79 * ownership of the file apart from the superu..ahem, Administrator. 80 * 81 * \li Inheritance is set to NO_INHERITANCE. 82 * 83 * Unix's dumbing down includes: 84 * 85 * \li The sticky bit cannot be set. 86 * 87 * \li setuid and setgid cannot be set. 88 * 89 * \li Only regular files and directories can be set. 90 * 91 * The rest of this comment discusses a few of the incompatibilities 92 * between the two systems that need more thought if this API is to 93 * be extended to accommodate them. 94 * 95 * The Windows standard access right "DELETE" doesn't have a direct 96 * equivalent in the Unix world, so it isn't clear what should be done 97 * with it. 98 * 99 * The Unix sticky bit is not supported. While NT does have a concept 100 * of allowing users to create files in a directory but not delete or 101 * rename them, it does not have a concept of allowing them to be deleted 102 * if they are owned by the user trying to delete/rename. While it is 103 * probable that something could be cobbled together in NT 5 with inheritance, 104 * it can't really be done in NT 4 as a single property that you could 105 * set on a directory. You'd need to coordinate something with file creation 106 * so that every file created had DELETE set for the owner but noone else. 107 * 108 * On Unix systems, setting #ISC_FSACCESS_LISTDIRECTORY sets READ. 109 * ... setting either #ISC_FSACCESS_CREATECHILD or #ISC_FSACCESS_DELETECHILD 110 * sets WRITE. 111 * ... setting #ISC_FSACCESS_ACCESSCHILD sets EXECUTE. 112 * 113 * On NT systems, setting #ISC_FSACCESS_LISTDIRECTORY sets FILE_LIST_DIRECTORY. 114 * ... setting #ISC_FSACCESS_CREATECHILD sets FILE_CREATE_CHILD independently. 115 * ... setting #ISC_FSACCESS_DELETECHILD sets FILE_DELETE_CHILD independently. 116 * ... setting #ISC_FSACCESS_ACCESSCHILD sets FILE_TRAVERSE. 117 * 118 * Unresolved: XXXDCL 119 * \li What NT access right controls the ability to rename a file? 120 * \li How does DELETE work? If a directory has FILE_DELETE_CHILD but a 121 * file or directory within it does not have DELETE, is that file 122 * or directory deletable? 123 * \li To implement isc_fsaccess_get(), mapping an existing Unix permission 124 * mode_t back to an isc_fsaccess_t is pretty trivial; however, mapping 125 * an NT DACL could be impossible to do in a responsible way. 126 * \li Similarly, trying to implement the functionality of being able to 127 * say "add group writability to whatever permissions already exist" 128 * could be tricky on NT because of the order-of-entry issue combined 129 * with possibly having one or more matching ACEs already explicitly 130 * granting or denying access. Because this functionality is 131 * not yet needed by the ISC, no code has been written to try to 132 * solve this problem. 133 */ 134 135 #include <isc/lang.h> 136 #include <isc/types.h> 137 138 /* 139 * Trustees. 140 */ 141 #define ISC_FSACCESS_OWNER 0x1 /*%< User account. */ 142 #define ISC_FSACCESS_GROUP 0x2 /*%< Primary group owner. */ 143 #define ISC_FSACCESS_OTHER 0x4 /*%< Not the owner or the group owner. */ 144 #define ISC_FSACCESS_WORLD 0x7 /*%< User, Group, Other. */ 145 146 /* 147 * Types of permission. 148 */ 149 #define ISC_FSACCESS_READ 0x00000001 /*%< File only. */ 150 #define ISC_FSACCESS_WRITE 0x00000002 /*%< File only. */ 151 #define ISC_FSACCESS_EXECUTE 0x00000004 /*%< File only. */ 152 #define ISC_FSACCESS_CREATECHILD 0x00000008 /*%< Dir only. */ 153 #define ISC_FSACCESS_DELETECHILD 0x00000010 /*%< Dir only. */ 154 #define ISC_FSACCESS_LISTDIRECTORY 0x00000020 /*%< Dir only. */ 155 #define ISC_FSACCESS_ACCESSCHILD 0x00000040 /*%< Dir only. */ 156 157 /*% 158 * Adding any permission bits beyond 0x200 would mean typedef'ing 159 * isc_fsaccess_t as isc_uint64_t, and redefining this value to 160 * reflect the new range of permission types, Probably to 21 for 161 * maximum flexibility. The number of bits has to accommodate all of 162 * the permission types, and three full sets of them have to fit 163 * within an isc_fsaccess_t. 164 */ 165 #define ISC__FSACCESS_PERMISSIONBITS 10 166 167 ISC_LANG_BEGINDECLS 168 169 void 170 isc_fsaccess_add(int trustee, int permission, isc_fsaccess_t *access); 171 172 void 173 isc_fsaccess_remove(int trustee, int permission, isc_fsaccess_t *access); 174 175 isc_result_t 176 isc_fsaccess_set(const char *path, isc_fsaccess_t access); 177 178 ISC_LANG_ENDDECLS 179 180 #endif /* ISC_FSACCESS_H */ 181