Reading the access attributes of directories in Windows

Thomas Jollans thomas at jollybox.de
Fri Aug 20 13:41:44 EDT 2010


On Friday 20 August 2010, it occurred to Nobody to exclaim:
> Unix lacks the "Append Data" permission for files, and the "Create Files",
> "Create Folders" and "Delete Subfolders and Files" correspond to having
> write permission on a directory.

How does append differ from write? If you have appending permissions, but not 
writing ones, is it impossible to seek? Or is there a more complex "block" 
that bites you when you seek to before the old end of file and try writing 
there?

Thank you for the insights, "Nobody". Makes me wonder whether SELinux makes 
changes in this area, and if so, how far-reaching they are.


> On Unix, you can read permissions (and attributes if the filesystem has
> them) for any file which you can "reach" (i.e. have "x" permission on all
> ancestor directories). You can only change permissions (and some
> attributes) if you own the file, and only root can change ownership (and
> change some attributes).
> 
> 2. Permissions can be inherited from the "parent object" (which isn't
> necessarily the parent folder). If you change a permission on the parent
> object, it automatically affects any file or folder which inherits the
> permission.
> 
> 3. The owner can be either a user or a group.

What about both?
 
> 4. On Windows, a file cannot be "given away" either by its owner or an
> administrator. You can grant the "Take Ownership" permission, but
> the recipient still has to explicitly change the ownership.

Really? So the operating system actually places restrictions on what the 
administrator can do? 

Or is there a fine distinction here between administrator-accounts in general 
and the NT "Administrator" account that at least some versions of Windows (xp 
home edition springs to mind) appear to try to hide as best they can ? Well, 
this is probably just my UNIX conditioning, expecting a single all-powerful 
super-user, shining through here -- but it does seam strange to have a super-
user that is not omnipotent.



More information about the Python-list mailing list