>> There might be a tiny few things which really are hard-coded to
>> Administrator (the user) and/or Administrators (the group), but I haven't
>> run into that.
>
> The only one I know of for sure is manipulating file system stuff.
> Partitioning a disk, reading the UNC, marking a file system dirty, etc.
> I don't know what privilege it is - maybe you actually can assign it.

Control Panel > Administrative Tools > Local Security Settings

Left pane: Local Policies > User Rights Assignment

Right pane says:

   Perform volume maintenance tasks: Administrators

Presumably this covers things like mounting/unmounting filesystems, 
creating partitions, formatting them, and so forth. (The frustrating 
thing about Windows is that you have to *guess*; this isn't written down 
anywhere.) If you change the setting here, you can allow other users to 
do this.

Also in there is "take ownership of files". In other words, bypass ACLs.

Note that everything in this pane refers to "Administrators" (the user 
group, not "Administrator" the user).

If you flip the left page to Local Policies > Security Options, there's 
more fun stuff to play with, for example:

   Devices: Allowed to format and eject removable media: Administrators

>>> That is the basic problem with complex permissions. :-)
>> I assume that comment is directed at AD.
>
> Well, all complex permissions systems.

As far as I can see, the existence of 3 different kinds of groups is an 
artefact of the way AD is implemented internally, and how it maintains 
backwards compatibility. Which is frustrating, because I don't care how 
it works, and I don't need backwards compatibility. I just want 
something comprehensible.

>> ...except that it's still implemented the old way.
>
> No it isn't. Well, maybe with XP, but I don't think that's the case any
> more.

And who's using anything newer than XP? I mean, really.

>> Which means that changing the parent's permissions has the intended
>> effect,
>> but if the parent has 80,000,000 children, it still takes forever to
>> set the
>> permissions, because you literally have to touch every child and
>> update its
>> ACL on disk.
>
> Maybe if you're doing it thru the explorer?

How else would you change a file's permissions?

>> Oh yeah. TRWTF is 8.3 names.
>
> What about them?

They still exist. And grown up programs sometimes end up using them.

>> Like I say, it's a shame you can't use this feature to launch stuff
>> programmatically. (At least, not without linking to C.)
>
> Well, what are you going to launch? You can't launch *anything* without
> linking to some sort of C code.

I mean, if you want to launch a program from the CLI, you just type its 
name. But there isn't a command like "open Blue.ogg" which will fire up 
the default application and load the named file. If you want to do this, 
you have to write C code to query the registry and so forth.

>> how it's implemented. (I have a sinking feeling it's a type database for
>> each file manager, rather than something that arbitrary applications
>> can use.)
>
> I wouldn't be surprised.

Actually, you know what? There's probably one type database for KDE, 
which only KDE applications can access using the KDE application 
libraries, and then a second, completely independent type database for 
GNOME, which only GNOME applications can access using the GNOME 
libraries. And then half a dozen CLI applications which use their own 
built-in mechanism.

And I've seen at least one Debian package which claims to contain a 
program for analysing file contents to determine their actual type...

In short, it's an incoherent nightmare, just like almost everything else 
in Unix.

>>> Even better, of course, would be having it in the actual metadata of the
>>> file, like the Mac's OS tried to do, except they did it before MIME was
>>> around, so it didn't work out as well as it might.
>>
>> Is that the whole resource fork / data fork thing? I never heard how that
>> actually works. (Other than "it doesn't".)
>
> No, it was the Creator/Type thing, each a four-character code. So a text
> file made by MS Word might have a creator/type or MSWD/TEXT or something.
>
> Mac files had two forks. One was the data fork, which is just like a
> UNIX file. The other is the resource fork, which had structured blobs,
> each defined by a type and a size, maybe a name, etc. So what you see in
> a Windows executable as a "resource" file was actually the resource fork
> of a Mac application or data file.

I see... I think! o_O

Post a reply to this message