ext2 and ext3 block reservations can be bypassed
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"elladan" == elladan <[email protected]> writes:
elladan> It's perfectly legal for the shell to sit around with a file elladan> open and pass it off to a child, even if the disk is full.
elladan> It's also perfectly legal for root to write to the fd, even elladan> if the disk is full (for normal users).
elladan> It just happens that the suid program wasn't the one who elladan> chose what file it was going to write stdout to - the shell elladan> did.
This is why in SVr4, struct cred is cloned at open time, and passed down to each VFS operation.
There's a choice of security modules here--- should the credentials of the opener or the credentials of the writer determine the use of the extra space? I think in this case it ought to be the credentials of the opener. Also, I'm not sure that mount(8) should be a setuid program. (I know it's convenient for floppy mounts, but I'd rather they were handled by autofs)
Peter C
Quoted 2 lines · Peter Chubb
This is why in SVr4, struct cred is cloned at open time, and passed down to each VFS operation.
That doesn't work for shared mappings over holes. Unfortunately. Yes, credentials cache a-la 4.4BSD would help in many cases, but we have no reasonably credentials when kswapd writes a dirty page on disk. It _can_ cause allocations. And many processes might've touched that page until it finally got written out - which credentials would you use?
Quoted 6 lines · Alexander Viro
Quoted 2 lines · Peter Chubb
This is why in SVr4, struct cred is cloned at open time, and passed down to each VFS operation.
Quoted 6 lines
That doesn't work for shared mappings over holes. Unfortunately. Yes, credentials cache a-la 4.4BSD would help in many cases, but we have no reasonably credentials when kswapd writes a dirty page on disk. It _can_ cause allocations. And many processes might've touched that page until it finally got written out - which credentials would you use?
I'd rather have the check done when the page gets dirty in the first place. Refuse the CoW if there is not diskspace to write it back. Right now we can go beyond the diskspace we are allowed to use and we will silently loose data if we go beyond the available diskspace.
Signature · 2 lines
Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:[email protected]
Quoted 14 lines · Kasper Dupont
Quoted 6 lines · Alexander Viro
Quoted 2 lines · Peter Chubb
This is why in SVr4, struct cred is cloned at open time, and passed down to each VFS operation.
Quoted 6 lines
That doesn't work for shared mappings over holes. Unfortunately. Yes, credentials cache a-la 4.4BSD would help in many cases, but we have no reasonably credentials when kswapd writes a dirty page on disk. It _can_ cause allocations. And many processes might've touched that page until it finally got written out - which credentials would you use?
Quoted 5 lines
I'd rather have the check done when the page gets dirty in the first place. Refuse the CoW if there is not diskspace to write it back. Right now we can go beyond the diskspace we are allowed to use and we will silently loose data if we go beyond the available diskspace.
So, the way this would work (presumably) is that space gets reserved on the filesystem as soon as the page goes dirty, if space is not presently allocated for that page. The process would receive a SIGBUS if they attempt to write to the page, but backing store reservation failed, as they do when, eg., there's an IO error on a page or some such.
If the mapping was held by more than one process, and one had permission to dirty the page and the other did not, then whose credentials should get used would just be a matter of which one writes first. If the disk is full for users and root dirties the page first, then the user can re-dirty it. If the user dirties it first, then the user receives SIGBUS. If the disk is full for everyone, then either one would receive the signal.
-J