1258945Sroberto/* 2258945Sroberto * Copyright (C) 2004-2007, 2009 Internet Systems Consortium, Inc. ("ISC") 3258945Sroberto * Copyright (C) 2000, 2001 Internet Software Consortium. 4258945Sroberto * 5258945Sroberto * Permission to use, copy, modify, and/or distribute this software for any 6258945Sroberto * purpose with or without fee is hereby granted, provided that the above 7258945Sroberto * copyright notice and this permission notice appear in all copies. 8258945Sroberto * 9258945Sroberto * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH 10258945Sroberto * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY 11258945Sroberto * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, 12258945Sroberto * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM 13258945Sroberto * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE 14258945Sroberto * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR 15258945Sroberto * PERFORMANCE OF THIS SOFTWARE. 16258945Sroberto */ 17258945Sroberto 18280849Scy/* $Id: fsaccess.h,v 1.16 2009/01/17 23:47:43 tbox Exp $ */ 19258945Sroberto 20258945Sroberto#ifndef ISC_FSACCESS_H 21258945Sroberto#define ISC_FSACCESS_H 1 22258945Sroberto 23258945Sroberto/*! \file isc/fsaccess.h 24258945Sroberto * \brief The ISC filesystem access module encapsulates the setting of file 25258945Sroberto * and directory access permissions into one API that is meant to be 26258945Sroberto * portable to multiple operating systems. 27258945Sroberto * 28258945Sroberto * The two primary operating system flavors that are initially accommodated 29258945Sroberto * are POSIX and Windows NT 4.0 and later. The Windows NT access model is 30258945Sroberto * considerable more flexible than POSIX's model (as much as I am loathe to 31258945Sroberto * admit it), and so the ISC API has a higher degree of complexity than would 32258945Sroberto * be needed to simply address POSIX's needs. 33258945Sroberto * 34258945Sroberto * The full breadth of NT's flexibility is not available either, for the 35258945Sroberto * present time. Much of it is to provide compatibility with what Unix 36258945Sroberto * programmers are expecting. This is also due to not yet really needing all 37258945Sroberto * of the functionality of an NT system (or, for that matter, a POSIX system) 38258945Sroberto * in BIND9, and so resolving how to handle the various incompatibilities has 39258945Sroberto * been a purely theoretical exercise with no operational experience to 40258945Sroberto * indicate how flawed the thinking may be. 41258945Sroberto * 42258945Sroberto * Some of the more notable dumbing down of NT for this API includes: 43258945Sroberto * 44258945Sroberto *\li Each of FILE_READ_DATA and FILE_READ_EA are set with #ISC_FSACCESS_READ. 45258945Sroberto * 46258945Sroberto * \li All of FILE_WRITE_DATA, FILE_WRITE_EA and FILE_APPEND_DATA are 47258945Sroberto * set with #ISC_FSACCESS_WRITE. FILE_WRITE_ATTRIBUTES is not set 48258945Sroberto * so as to be consistent with Unix, where only the owner of the file 49258945Sroberto * or the superuser can change the attributes/mode of a file. 50258945Sroberto * 51258945Sroberto * \li Both of FILE_ADD_FILE and FILE_ADD_SUBDIRECTORY are set with 52258945Sroberto * #ISC_FSACCESS_CREATECHILD. This is similar to setting the WRITE 53258945Sroberto * permission on a Unix directory. 54258945Sroberto * 55258945Sroberto * \li SYNCHRONIZE is always set for files and directories, unless someone 56258945Sroberto * can give me a reason why this is a bad idea. 57258945Sroberto * 58258945Sroberto * \li READ_CONTROL and FILE_READ_ATTRIBUTES are always set; this is 59258945Sroberto * consistent with Unix, where any file or directory can be stat()'d 60258945Sroberto * unless the directory path disallows complete access somewhere along 61258945Sroberto * the way. 62258945Sroberto * 63258945Sroberto * \li WRITE_DAC is only set for the owner. This too is consistent with 64258945Sroberto * Unix, and is tighter security than allowing anyone else to be 65258945Sroberto * able to set permissions. 66258945Sroberto * 67258945Sroberto * \li DELETE is only set for the owner. On Unix the ability to delete 68258945Sroberto * a file is controlled by the directory permissions, but it isn't 69258945Sroberto * currently clear to me what happens on NT if the directory has 70258945Sroberto * FILE_DELETE_CHILD set but a file within it does not have DELETE 71258945Sroberto * set. Always setting DELETE on the file/directory for the owner 72258945Sroberto * gives maximum flexibility to the owner without exposing the 73258945Sroberto * file to deletion by others. 74258945Sroberto * 75258945Sroberto * \li WRITE_OWNER is never set. This too is consistent with Unix, 76258945Sroberto * and is also tighter security than allowing anyone to change the 77258945Sroberto * ownership of the file apart from the superu..ahem, Administrator. 78258945Sroberto * 79258945Sroberto * \li Inheritance is set to NO_INHERITANCE. 80258945Sroberto * 81258945Sroberto * Unix's dumbing down includes: 82258945Sroberto * 83258945Sroberto * \li The sticky bit cannot be set. 84258945Sroberto * 85258945Sroberto * \li setuid and setgid cannot be set. 86258945Sroberto * 87258945Sroberto * \li Only regular files and directories can be set. 88258945Sroberto * 89258945Sroberto * The rest of this comment discusses a few of the incompatibilities 90258945Sroberto * between the two systems that need more thought if this API is to 91258945Sroberto * be extended to accommodate them. 92258945Sroberto * 93258945Sroberto * The Windows standard access right "DELETE" doesn't have a direct 94258945Sroberto * equivalent in the Unix world, so it isn't clear what should be done 95258945Sroberto * with it. 96258945Sroberto * 97258945Sroberto * The Unix sticky bit is not supported. While NT does have a concept 98258945Sroberto * of allowing users to create files in a directory but not delete or 99258945Sroberto * rename them, it does not have a concept of allowing them to be deleted 100258945Sroberto * if they are owned by the user trying to delete/rename. While it is 101258945Sroberto * probable that something could be cobbled together in NT 5 with inheritance, 102258945Sroberto * it can't really be done in NT 4 as a single property that you could 103258945Sroberto * set on a directory. You'd need to coordinate something with file creation 104258945Sroberto * so that every file created had DELETE set for the owner but noone else. 105258945Sroberto * 106258945Sroberto * On Unix systems, setting #ISC_FSACCESS_LISTDIRECTORY sets READ. 107258945Sroberto * ... setting either #ISC_FSACCESS_CREATECHILD or #ISC_FSACCESS_DELETECHILD 108258945Sroberto * sets WRITE. 109258945Sroberto * ... setting #ISC_FSACCESS_ACCESSCHILD sets EXECUTE. 110258945Sroberto * 111258945Sroberto * On NT systems, setting #ISC_FSACCESS_LISTDIRECTORY sets FILE_LIST_DIRECTORY. 112258945Sroberto * ... setting #ISC_FSACCESS_CREATECHILD sets FILE_CREATE_CHILD independently. 113258945Sroberto * ... setting #ISC_FSACCESS_DELETECHILD sets FILE_DELETE_CHILD independently. 114258945Sroberto * ... setting #ISC_FSACCESS_ACCESSCHILD sets FILE_TRAVERSE. 115258945Sroberto * 116258945Sroberto * Unresolved: XXXDCL 117258945Sroberto * \li What NT access right controls the ability to rename a file? 118258945Sroberto * \li How does DELETE work? If a directory has FILE_DELETE_CHILD but a 119258945Sroberto * file or directory within it does not have DELETE, is that file 120258945Sroberto * or directory deletable? 121258945Sroberto * \li To implement isc_fsaccess_get(), mapping an existing Unix permission 122258945Sroberto * mode_t back to an isc_fsaccess_t is pretty trivial; however, mapping 123258945Sroberto * an NT DACL could be impossible to do in a responsible way. 124258945Sroberto * \li Similarly, trying to implement the functionality of being able to 125258945Sroberto * say "add group writability to whatever permissions already exist" 126258945Sroberto * could be tricky on NT because of the order-of-entry issue combined 127258945Sroberto * with possibly having one or more matching ACEs already explicitly 128258945Sroberto * granting or denying access. Because this functionality is 129258945Sroberto * not yet needed by the ISC, no code has been written to try to 130258945Sroberto * solve this problem. 131258945Sroberto */ 132258945Sroberto 133258945Sroberto#include <isc/lang.h> 134258945Sroberto#include <isc/types.h> 135258945Sroberto 136258945Sroberto/* 137258945Sroberto * Trustees. 138258945Sroberto */ 139258945Sroberto#define ISC_FSACCESS_OWNER 0x1 /*%< User account. */ 140258945Sroberto#define ISC_FSACCESS_GROUP 0x2 /*%< Primary group owner. */ 141258945Sroberto#define ISC_FSACCESS_OTHER 0x4 /*%< Not the owner or the group owner. */ 142258945Sroberto#define ISC_FSACCESS_WORLD 0x7 /*%< User, Group, Other. */ 143258945Sroberto 144258945Sroberto/* 145258945Sroberto * Types of permission. 146258945Sroberto */ 147258945Sroberto#define ISC_FSACCESS_READ 0x00000001 /*%< File only. */ 148258945Sroberto#define ISC_FSACCESS_WRITE 0x00000002 /*%< File only. */ 149258945Sroberto#define ISC_FSACCESS_EXECUTE 0x00000004 /*%< File only. */ 150258945Sroberto#define ISC_FSACCESS_CREATECHILD 0x00000008 /*%< Dir only. */ 151258945Sroberto#define ISC_FSACCESS_DELETECHILD 0x00000010 /*%< Dir only. */ 152258945Sroberto#define ISC_FSACCESS_LISTDIRECTORY 0x00000020 /*%< Dir only. */ 153258945Sroberto#define ISC_FSACCESS_ACCESSCHILD 0x00000040 /*%< Dir only. */ 154258945Sroberto 155258945Sroberto/*% 156258945Sroberto * Adding any permission bits beyond 0x200 would mean typedef'ing 157258945Sroberto * isc_fsaccess_t as isc_uint64_t, and redefining this value to 158258945Sroberto * reflect the new range of permission types, Probably to 21 for 159258945Sroberto * maximum flexibility. The number of bits has to accommodate all of 160258945Sroberto * the permission types, and three full sets of them have to fit 161258945Sroberto * within an isc_fsaccess_t. 162258945Sroberto */ 163258945Sroberto#define ISC__FSACCESS_PERMISSIONBITS 10 164258945Sroberto 165258945SrobertoISC_LANG_BEGINDECLS 166258945Sroberto 167258945Srobertovoid 168258945Srobertoisc_fsaccess_add(int trustee, int permission, isc_fsaccess_t *access); 169258945Sroberto 170258945Srobertovoid 171258945Srobertoisc_fsaccess_remove(int trustee, int permission, isc_fsaccess_t *access); 172258945Sroberto 173258945Srobertoisc_result_t 174258945Srobertoisc_fsaccess_set(const char *path, isc_fsaccess_t access); 175258945Sroberto 176258945SrobertoISC_LANG_ENDDECLS 177258945Sroberto 178258945Sroberto#endif /* ISC_FSACCESS_H */ 179