On 5/19/2011 8:41, Invisible wrote:
> No. But if you can take ownership of a file, you can give yourself
> permission to access it, even if you didn't have that permission to start
> with. In other words, it allows you to bypass ACLs.

Sure, but then you own the file. I.e., you get caught. :-)  And you can't 
put it back the way it was, either.

>> The command is "start".
> And that works for any file type which Windows has a file association for?

As far as I know, yes.

> Well, no, Apache doesn't need to know what to open it with at all. It just
> needs to know what MIME type to claim it is.

Well, yes, that too. Which is why the desktops probably have different files.

> (Which might potentially vary
> on a file-by-file basis in a way unrelated to the extension on the name...)

Not in the original apache. :-)

> Still not really seeing why you need this implemented at the filesystem
> level, but yeah...

You don't *need* anything at all at the filesystem level. You don't need 
directories, or locking, or ACLs. FORTH works fine without any of that.

That said, there's a benefit to having everyone use the same abstractions by 
building them into the file system. When they're baked into the OS, everyone 
does it the same way (so they're compatible) and nobody needs to have code 
to deal with it in every application. The idea that "we don't need that in 
the OS because we can implement it again and again in every application that 
needs it" (especially when it's very close to every application that needs 
it) is a broken philosophy.

As another example, the mainframe I worked on had keyed files. That meant 
you could put a number on each line, and the editor could change individual 
lines of the files without rewriting the entire file or even reading the 
whole thing into memory. If you read the file "sequentially", you got it 
back in line-number order. So you had a bunch of editors that physically 
stored basically sorted hash tables (b-trees) of text lines, and a bunch of 
compilers each of which could read what the editor wrote in the order the 
editor expected them to read it. Now, if I want to edit a file bigger than 
memory, I need to use sed instead of vi.

> Do overlays matter any more? (Clearly they did once...)

Not unless you're using a machine that can't handle demand paging. 
Relatively few such machines nowadays don't have enough RAM to run 
everything at once, but there are still some around. Stuff like credit card 
terminals, for example.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 19/05/2011 05:03 PM, Darren New wrote:
> On 5/19/2011 8:41, Invisible wrote:
>> No. But if you can take ownership of a file, you can give yourself
>> permission to access it, even if you didn't have that permission to start
>> with. In other words, it allows you to bypass ACLs.
>
> Sure, but then you own the file. I.e., you get caught. :-) And you can't
> put it back the way it was, either.

Well, yeah, if you're worried about catching people, turn on file access 
auditing. (Something else which, AFAIK, Linux doesn't have.) I'm just 
saying people with this priviledge can access stuff they shouldn't be 
able to look at.

>> Still not really seeing why you need this implemented at the filesystem
>> level, but yeah...
>
> You don't *need* anything at all at the filesystem level. You don't need
> directories, or locking, or ACLs. FORTH works fine without any of that.
>
> That said, there's a benefit to having everyone use the same
> abstractions by building them into the file system. When they're baked
> into the OS, everyone does it the same way (so they're compatible) and
> nobody needs to have code to deal with it in every application. The idea
> that "we don't need that in the OS because we can implement it again and
> again in every application that needs it" (especially when it's very
> close to every application that needs it) is a broken philosophy.

Fair enough. For example, under Linux there are apparently at least 3 
different [incompatible] ways to access the sound hardware. Isn't that 
wonderful?

>> Do overlays matter any more? (Clearly they did once...)
>
> Not unless you're using a machine that can't handle demand paging.
> Relatively few such machines nowadays don't have enough RAM to run
> everything at once, but there are still some around. Stuff like credit
> card terminals, for example.

Right. So for desktop computers it's a non-issue?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 5/19/2011 11:18, Orchid XP v8 wrote:
> people with this priviledge can access stuff they shouldn't be able to look at.

Sure. But that's different from bypassing the ACLs. :-)

If you really want to prevent that, encrypt the file. (Something else Linux 
doesn't have quite the same.)

> Fair enough. For example, under Linux there are apparently at least 3
> different [incompatible] ways to access the sound hardware. Isn't that
> wonderful?

Actually, I think there's one way to access the sound hardware: /dev/audio. 
There's a variety of servers acting as intermediaries, because for the most 
part, while UNIX is a multi-user system, they never quite got the whole 
"login" concept into the system.

> Right. So for desktop computers it's a non-issue?

Pretty much, yes. As I said, anything with demand paging is probably not 
going to bother supporting overlays.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message