On Thu, 07 Oct 2004 08:41:30 -0700, Nathan Grennan > Security contexts are generally hidden, their are so many more, and are > a lot more complex. Owner/Group/Permissions/Umask are setup in such a > way that they generally not a problem, unlike security contexts. I think there is a strong point about complexity of the settings space. The fact that ownership permission and umask use a small finite settings space makes the ui for changing those settings managable across a number of tools. For example lftp client understands chmod. does it understand restorecon? > I think this is asking too much, especially when the complexity level is > such that users won't generally be manually setting security context, > but letting the system figure out the correct context for them via > restorecon I think there is a point here too.. but let me rephrase it by asking a question. Is there ever any value in having files in a path NOT be the correct security context for that path? If there is never any value in leaving security contexts 'stale' after a mv operation, and it is always expected that a user will be required to run restorecon for useful operation. It seems reasonable to me that mv should be applying the correct context for the new path location automatically. Are there tools in userspace with 'reasonable' ui that would let a user manually change context on a subset of files contrary to what restorecon would do? If there is a lack of tools that let users delibrately create out of sync security contexts, thats a major difference between how ownership and permissions are handled. -jef"notice all those if's....."spaleta
