Re: 'native files', 'object fingerprints' [was: sendpath()]
Hi!
> struct safe_kpointer {
> void *kaddr;
> unsigned long fingerprint[4];
> };
>
> the kernel can validate kaddr by 1) validating the pointer via the master
> fingerprint (every valid kernel pointer must point to a structure that
> starts with the master fingerprint's copy). Then usage-permissions are
> validated by checking the file fingerprint (the per-object fingerprint).
>
> this is a safe, very fast [ O(1) ] object-permission model. (it's a
> variation of a former idea of yours.) A process can pass object
> fingerprints and kernel pointers to other processes too - thus the other
> process can access the object too. Threads will 'naturally' share objects,
> because fingerprints are typically stored in memory.
I do not know if I'd trust this.
First,
(fd < current->fdlimit && current->fdlist[fd])
if O(1), too. Sure, passing those is slightly hard, but we can do that already.
With your proposal, all hopes for fuser and revoke are out.
Ouch; you say process can pass it to other process. How will kernel know not
to free fd until _both_ freed it?
Plus, you are playing tricks with random numbers. Up to now, only ssh and
similar depended on random numbers. Now kernel relies on them during boot.
Notice that most important "master fingerprint" is generated first. At that
timeyou might not have enough entropy in your pools.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
Hi!
struct safe_kpointer {
void *kaddr;
unsigned long fingerprint[4];
};
the kernel can validate kaddr by 1) validating the pointer via the master
fingerprint (every valid kernel pointer must point to a structure that
starts with the master fingerprint's copy). Then usage-permissions are
validated by checking the file fingerprint (the per-object fingerprint).
this is a safe, very fast [ O(1) ] object-permission model. (it's a
variation of a former idea of yours.) A process can pass object
fingerprints and kernel pointers to other processes too - thus the other
process can access the object too. Threads will 'naturally' share objects,
because fingerprints are typically stored in memory.
I do not know if I'd trust this.
First,
(fd current-fdlimit current-fdlist[fd])
if O(1), too. Sure, passing those is slightly hard, but we can do that already.
With your proposal, all hopes for fuser and revoke are out.
Ouch; you say process can pass it to other process. How will kernel know not
to free fd until _both_ freed it?
Plus, you are playing tricks with random numbers. Up to now, only ssh and
similar depended on random numbers. Now kernel relies on them during boot.
Notice that most important "master fingerprint" is generated first. At that
timeyou might not have enough entropy in your pools.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
Hi!
> struct safe_kpointer {
> void *kaddr;
> unsigned long fingerprint[4];
> };
>
> the kernel can validate kaddr by 1) validating the pointer via the master
> fingerprint (every valid kernel pointer must point to a structure that
> starts with the master fingerprint's copy). Then usage-permissions are
> validated by checking the file fingerprint (the per-object fingerprint).
>
> this is a safe, very fast [ O(1) ] object-permission model. (it's a
> variation of a former idea of yours.) A process can pass object
> fingerprints and kernel pointers to other processes too - thus the other
> process can access the object too. Threads will 'naturally' share objects,
> because fingerprints are typically stored in memory.
I do not know if I'd trust this.
First,
(fd < current->fdlimit && current->fdlist[fd])
if O(1), too. Sure, passing those is slightly hard, but we can do that already.
With your proposal, all hopes for fuser and revoke are out.
Ouch; you say process can pass it to other process. How will kernel know not
to free fd until _both_ freed it?
Plus, you are playing tricks with random numbers. Up to now, only ssh and
similar depended on random numbers. Now kernel relies on them during boot.
Notice that most important "master fingerprint" is generated first. At that
timeyou might not have enough entropy in your pools.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
Hi!
struct safe_kpointer {
void *kaddr;
unsigned long fingerprint[4];
};
the kernel can validate kaddr by 1) validating the pointer via the master
fingerprint (every valid kernel pointer must point to a structure that
starts with the master fingerprint's copy). Then usage-permissions are
validated by checking the file fingerprint (the per-object fingerprint).
this is a safe, very fast [ O(1) ] object-permission model. (it's a
variation of a former idea of yours.) A process can pass object
fingerprints and kernel pointers to other processes too - thus the other
process can access the object too. Threads will 'naturally' share objects,
because fingerprints are typically stored in memory.
I do not know if I'd trust this.
First,
(fd current-fdlimit current-fdlist[fd])
if O(1), too. Sure, passing those is slightly hard, but we can do that already.
With your proposal, all hopes for fuser and revoke are out.
Ouch; you say process can pass it to other process. How will kernel know not
to free fd until _both_ freed it?
Plus, you are playing tricks with random numbers. Up to now, only ssh and
similar depended on random numbers. Now kernel relies on them during boot.
Notice that most important "master fingerprint" is generated first. At that
timeyou might not have enough entropy in your pools.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
On Tue, 16 Jan 2001, Ingo Molnar wrote:
> But even user-space code could use 'native files', via the following, safe
> mechanizm:
so here's an alternative to ingo's proposal which i think solves some of
the other objections raised. it's something i've proposed in the past
under the name "extended file handles".
struct extended_file_permission {
int refcount;
some form of mutex to protect refcount;
some list structure head;
};
struct extended_file {
struct file *file;
struct extended_file_permission *perm;
whatever list foo is needed to link with extended_file_perm above;
};
if you allocate a few huge arrays of struct extended_file, then you can
verify if a pointer passed from user space fits into one of those arrays
pretty quickly.
struct task has a struct extended_file_permission * added to it to
indicate which perm struct that task is associated with.
so you just compare the f->perm to current->extended_file_perm and you
know if the task is allowed to use it or not.
clone() allows you to create tasks sharing the same
extended_file_permissions.
fork()/exec() would create new extended_file_perms -- which implicitly
causes all those files to be closed. this gives you pretty light cgi
fork()/exec() off a main "process" which is handling thousands of sockets.
i also proposed various methods of doing O_foo flag inheritance... but the
above is more interesting.
-dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
On Tue, 16 Jan 2001, Ingo Molnar wrote: > > yep, correct. But take a look at the trick it does with file descriptors, > i believe it could be a useful way of doing things. It basically > privatizes a struct file, without inserting it into the enumerated file > descriptors. This shows that 'native files' are possible: file struct > without file descriptor integers mapped to them. That's nothing new: the exec() code does exactly the same. In fact, there's a function for it: filp_open() and filp_close(). Which do a better job of it than your private implementation did, I suspect. I don't think your object fingerprints are anything more generic than the current file descriptors. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was: sendpath()]]
Thus spake Ingo Molnar ([EMAIL PROTECTED]): > if you read my (radical) proposal, the identification is based on a kernel > pointer and a 256-bit random integer. So non-negative integers are not > needed. (file-IO system-calls would be modified to detect if 'Unix file > descriptors' or pointers to 'native file descriptors' are passed to them, > so this is truly radical.) Yuck, don't pass pointers in kernel space to user space! NT does it and look what kernel call argument verification havoc it wrought over them! Felix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
Thus spake Ingo Molnar ([EMAIL PROTECTED]): > But even user-space code could use 'native files', via the following, safe > mechanizm: [something reminiscient of a token from a capability system] > (this 'fingerprint' mechanizm can be used for any object, not only files.) One good thing about tokens is that file handles can be implemented on top of them in user space. On the other hand, there already are mechanisms to pass file descriptors around and so on, so you don't gain anything tangible from your efford. I would advise reading some text books about capability systems, there is a lot to be learned here. But retrofitting something like this on an existing kernel is probably not a very good idea. Experience shows that you can't "un-bloat" a piece of software by introducing a few elegant concepts. The compatibility stuff eats most of the benefits. Felix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
Ingo Molnar wrote:
> struct native_file {
> unsigned long master_fingerprint[8];
> unsigned long file_fingerprint[8];
> struct file file;
> };
>
> 'fingerprints' are 256 bit, true random numbers. master_fingerprint is
> global to the kernel and is generated once per boot. It validates the
> pointer of the structure. The master fingerprint is never known to
> user-space.
>
> file_fingerprint is a 256-bit identifier generated for this native file.
> The file fingerprint and the (kernel) pointer to the native file is
> returned to user-space. The cryptographical safety of these 256-bit random
> numbers guarantees that no breach can occur in a reasonable period of
> time. It's in essence an 'encrypted' communication between kernel and
> user-space.
Sounds similar to the Hurd...
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was: sendpath()]]
Ingo Molnar wrote: > - probably the most radical solution is what i suggested, to completely > avoid the unique-mapping of file structures to an integer range, and use > the address of the file structure (and some cookies) as an identification. IMO... gross. We do pretty much this exact thing in the ATM code (for the signalling daemon and the kernel exchainging status on VCCs) and it's pretty disgusting. I want to make it go away. > - a less radical solution would be to still map file structures to an > integer range (file descriptors) and usage-maintain files per processes, > but relax the 'allocate first non-allocated integer in the range' rule. [...] > fd = open(...,O_ANY); Yeah, this gets talked about, but I don't think a new flag for open is a good way to do this, because open() isn't the only thing that returns a new fd. What about socket()? pipe()? Maybe we could have a new prctl() control that turns this behavior on and off. Then you'd just have to be careful to turn it back off before calling any library functions that require ordering (like popen). Other than that, I think it'd be a good idea, especially if it could be implemented clean enough to make it CONFIG_'urable. That can't really be fairly judged until someone produces the code. -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was: sendpath()]]
On Tue, Jan 16, 2001 at 01:04:22PM +0100, Ingo Molnar wrote:
> - a less radical solution would be to still map file structures to an
> integer range (file descriptors) and usage-maintain files per processes,
> but relax the 'allocate first non-allocated integer in the range' rule.
> I'm not sure exactly how simple this is, but something like this should
> work: on close()-ing file descriptors the freed file descriptors would be
> cached in a list (this needs a new, separate structure which must be
> allocated/freed as well). Something like:
>
> struct lazy_filedesc {
> int fd;
> struct file *file;
> }
More generic file -> fd mapping would be useful to speed up poll() too,
because the event trigger could directly modify the poll table without
a second slow walk over the whole table.
So you could add another bit that tells if the fd is open or closed
and share it with poll.
Also in that table you could just keep a linked ordered free list
and not use GFP_ANY, because getting the lowest would be rather cheap.
Disadvantage is that it would need more cache and more overhead than
the current scheme.
[in a way it is a ugly duck like pte<->vma links]
> - Best-case overhead saves us a get_unused_fd() call, which can be *very*
> expensive (in terms of CPU time and cache footprint) if thousands of
> files are used. If O_ANY is used mostly, then the best-case is always
> triggered.
Really? Does the open_fds bitmap get that big ?
Maybe it just needs a faster find_next_zero_bit() @)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was: sendpath()]]
[Ingo Molnar] > - probably the most radical solution is what i suggested, to > completely avoid the unique-mapping of file structures to an integer > range, and use the address of the file structure (and some cookies) > as an identification. Careful, these must cast to non-negative integers, without clashing. > fd = open(...,O_ANY); I like this idea, but call it O_ALLOCANYFD. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
On Tue, Jan 16, 2001 at 12:26:12PM +0100, Ingo Molnar wrote: > > On Tue, 16 Jan 2001, Andi Kleen wrote: > > > On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote: > > > this is a safe, very fast [ O(1) ] object-permission model. (it's a > > > variation of a former idea of yours.) A process can pass object > > > fingerprints and kernel pointers to other processes too - thus the other > > > process can access the object too. Threads will 'naturally' share objects, > > >... > > > > Just setuid etc. doesn't work with that because access cannot be > > easily revoked without disturbing other clients. > > well, you cannot easily close() an already shared file descriptor in > another process's context either. Is revocation so important? Why is > setuid() a problem? A native file is just like a normal file, with the > difference that not an integer but a fingerprint identifies it, and that > access and usage counts are not automatically inherited across some > explicit sharing interface. Actually on second thought exec() is more a problem than setuid(), because it requires closing for file descriptors. So if you could devise a security model that doesn't depend on exec giving you a clean plate -- then it could work, but would probably not be very unixy. I'm amazed how non flamed you can present radical API ideas though, I even get flamed for much smaller things (like using text errors to replace the hundreds of EINVALs in the rtnetlink message interface) ;);) > > perhaps we could get most of the advantages by allowing the relaxation of > the 'allocate first free file descriptor number' rule for normal Unix > files? Not sure I follow. You mean dup2() ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
On Tue, 16 Jan 2001, Andi Kleen wrote: > On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote: > > this is a safe, very fast [ O(1) ] object-permission model. (it's a > > variation of a former idea of yours.) A process can pass object > > fingerprints and kernel pointers to other processes too - thus the other > > process can access the object too. Threads will 'naturally' share objects, > >... > > Just setuid etc. doesn't work with that because access cannot be > easily revoked without disturbing other clients. well, you cannot easily close() an already shared file descriptor in another process's context either. Is revocation so important? Why is setuid() a problem? A native file is just like a normal file, with the difference that not an integer but a fingerprint identifies it, and that access and usage counts are not automatically inherited across some explicit sharing interface. perhaps we could get most of the advantages by allowing the relaxation of the 'allocate first free file descriptor number' rule for normal Unix files? > Also the model depends on good secure random numbers, which is > questionable in many environments (e.g. a diskless box where the > random device effectively gets no new input) true, although newer chipsets include hardware random generators. But indeed, object fingerprints (tokens? ids?) make the random generator a much more central thing. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote: > this is a safe, very fast [ O(1) ] object-permission model. (it's a > variation of a former idea of yours.) A process can pass object > fingerprints and kernel pointers to other processes too - thus the other > process can access the object too. Threads will 'naturally' share objects, >... Just setuid etc. doesn't work with that because access cannot be easily revoked without disturbing other clients. To handle that you would probably need a "relookup if needed" mechanism similar to what NFSv4 has, so that you can force other users to relookup after you revoked a key. That complicates the use a lot though. Also the model depends on good secure random numbers, which is questionable in many environments (e.g. a diskless box where the random device effectively gets no new input) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote: this is a safe, very fast [ O(1) ] object-permission model. (it's a variation of a former idea of yours.) A process can pass object fingerprints and kernel pointers to other processes too - thus the other process can access the object too. Threads will 'naturally' share objects, ... Just setuid etc. doesn't work with that because access cannot be easily revoked without disturbing other clients. To handle that you would probably need a "relookup if needed" mechanism similar to what NFSv4 has, so that you can force other users to relookup after you revoked a key. That complicates the use a lot though. Also the model depends on good secure random numbers, which is questionable in many environments (e.g. a diskless box where the random device effectively gets no new input) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
On Tue, 16 Jan 2001, Andi Kleen wrote: On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote: this is a safe, very fast [ O(1) ] object-permission model. (it's a variation of a former idea of yours.) A process can pass object fingerprints and kernel pointers to other processes too - thus the other process can access the object too. Threads will 'naturally' share objects, ... Just setuid etc. doesn't work with that because access cannot be easily revoked without disturbing other clients. well, you cannot easily close() an already shared file descriptor in another process's context either. Is revocation so important? Why is setuid() a problem? A native file is just like a normal file, with the difference that not an integer but a fingerprint identifies it, and that access and usage counts are not automatically inherited across some explicit sharing interface. perhaps we could get most of the advantages by allowing the relaxation of the 'allocate first free file descriptor number' rule for normal Unix files? Also the model depends on good secure random numbers, which is questionable in many environments (e.g. a diskless box where the random device effectively gets no new input) true, although newer chipsets include hardware random generators. But indeed, object fingerprints (tokens? ids?) make the random generator a much more central thing. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
On Tue, Jan 16, 2001 at 12:26:12PM +0100, Ingo Molnar wrote: On Tue, 16 Jan 2001, Andi Kleen wrote: On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote: this is a safe, very fast [ O(1) ] object-permission model. (it's a variation of a former idea of yours.) A process can pass object fingerprints and kernel pointers to other processes too - thus the other process can access the object too. Threads will 'naturally' share objects, ... Just setuid etc. doesn't work with that because access cannot be easily revoked without disturbing other clients. well, you cannot easily close() an already shared file descriptor in another process's context either. Is revocation so important? Why is setuid() a problem? A native file is just like a normal file, with the difference that not an integer but a fingerprint identifies it, and that access and usage counts are not automatically inherited across some explicit sharing interface. Actually on second thought exec() is more a problem than setuid(), because it requires closing for file descriptors. So if you could devise a security model that doesn't depend on exec giving you a clean plate -- then it could work, but would probably not be very unixy. I'm amazed how non flamed you can present radical API ideas though, I even get flamed for much smaller things (like using text errors to replace the hundreds of EINVALs in the rtnetlink message interface) ;);) perhaps we could get most of the advantages by allowing the relaxation of the 'allocate first free file descriptor number' rule for normal Unix files? Not sure I follow. You mean dup2() ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was: sendpath()]]
[Ingo Molnar] - probably the most radical solution is what i suggested, to completely avoid the unique-mapping of file structures to an integer range, and use the address of the file structure (and some cookies) as an identification. Careful, these must cast to non-negative integers, without clashing. fd = open(...,O_ANY); I like this idea, but call it O_ALLOCANYFD. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was: sendpath()]]
On Tue, Jan 16, 2001 at 01:04:22PM +0100, Ingo Molnar wrote:
- a less radical solution would be to still map file structures to an
integer range (file descriptors) and usage-maintain files per processes,
but relax the 'allocate first non-allocated integer in the range' rule.
I'm not sure exactly how simple this is, but something like this should
work: on close()-ing file descriptors the freed file descriptors would be
cached in a list (this needs a new, separate structure which must be
allocated/freed as well). Something like:
struct lazy_filedesc {
int fd;
struct file *file;
}
More generic file - fd mapping would be useful to speed up poll() too,
because the event trigger could directly modify the poll table without
a second slow walk over the whole table.
So you could add another bit that tells if the fd is open or closed
and share it with poll.
Also in that table you could just keep a linked ordered free list
and not use GFP_ANY, because getting the lowest would be rather cheap.
Disadvantage is that it would need more cache and more overhead than
the current scheme.
[in a way it is a ugly duck like pte-vma links]
- Best-case overhead saves us a get_unused_fd() call, which can be *very*
expensive (in terms of CPU time and cache footprint) if thousands of
files are used. If O_ANY is used mostly, then the best-case is always
triggered.
Really? Does the open_fds bitmap get that big ?
Maybe it just needs a faster find_next_zero_bit() @)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was: sendpath()]]
Ingo Molnar wrote: - probably the most radical solution is what i suggested, to completely avoid the unique-mapping of file structures to an integer range, and use the address of the file structure (and some cookies) as an identification. IMO... gross. We do pretty much this exact thing in the ATM code (for the signalling daemon and the kernel exchainging status on VCCs) and it's pretty disgusting. I want to make it go away. - a less radical solution would be to still map file structures to an integer range (file descriptors) and usage-maintain files per processes, but relax the 'allocate first non-allocated integer in the range' rule. [...] fd = open(...,O_ANY); Yeah, this gets talked about, but I don't think a new flag for open is a good way to do this, because open() isn't the only thing that returns a new fd. What about socket()? pipe()? Maybe we could have a new prctl() control that turns this behavior on and off. Then you'd just have to be careful to turn it back off before calling any library functions that require ordering (like popen). Other than that, I think it'd be a good idea, especially if it could be implemented clean enough to make it CONFIG_'urable. That can't really be fairly judged until someone produces the code. -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
Ingo Molnar wrote:
struct native_file {
unsigned long master_fingerprint[8];
unsigned long file_fingerprint[8];
struct file file;
};
'fingerprints' are 256 bit, true random numbers. master_fingerprint is
global to the kernel and is generated once per boot. It validates the
pointer of the structure. The master fingerprint is never known to
user-space.
file_fingerprint is a 256-bit identifier generated for this native file.
The file fingerprint and the (kernel) pointer to the native file is
returned to user-space. The cryptographical safety of these 256-bit random
numbers guarantees that no breach can occur in a reasonable period of
time. It's in essence an 'encrypted' communication between kernel and
user-space.
Sounds similar to the Hurd...
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was: sendpath()]]
Thus spake Ingo Molnar ([EMAIL PROTECTED]): if you read my (radical) proposal, the identification is based on a kernel pointer and a 256-bit random integer. So non-negative integers are not needed. (file-IO system-calls would be modified to detect if 'Unix file descriptors' or pointers to 'native file descriptors' are passed to them, so this is truly radical.) Yuck, don't pass pointers in kernel space to user space! NT does it and look what kernel call argument verification havoc it wrought over them! Felix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
On Tue, 16 Jan 2001, Ingo Molnar wrote: yep, correct. But take a look at the trick it does with file descriptors, i believe it could be a useful way of doing things. It basically privatizes a struct file, without inserting it into the enumerated file descriptors. This shows that 'native files' are possible: file struct without file descriptor integers mapped to them. That's nothing new: the exec() code does exactly the same. In fact, there's a function for it: filp_open() and filp_close(). Which do a better job of it than your private implementation did, I suspect. I don't think your object fingerprints are anything more generic than the current file descriptors. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 'native files', 'object fingerprints' [was: sendpath()]
On Tue, 16 Jan 2001, Ingo Molnar wrote:
But even user-space code could use 'native files', via the following, safe
mechanizm:
so here's an alternative to ingo's proposal which i think solves some of
the other objections raised. it's something i've proposed in the past
under the name "extended file handles".
struct extended_file_permission {
int refcount;
some form of mutex to protect refcount;
some list structure head;
};
struct extended_file {
struct file *file;
struct extended_file_permission *perm;
whatever list foo is needed to link with extended_file_perm above;
};
if you allocate a few huge arrays of struct extended_file, then you can
verify if a pointer passed from user space fits into one of those arrays
pretty quickly.
struct task has a struct extended_file_permission * added to it to
indicate which perm struct that task is associated with.
so you just compare the f-perm to current-extended_file_perm and you
know if the task is allowed to use it or not.
clone() allows you to create tasks sharing the same
extended_file_permissions.
fork()/exec() would create new extended_file_perms -- which implicitly
causes all those files to be closed. this gives you pretty light cgi
fork()/exec() off a main "process" which is handling thousands of sockets.
i also proposed various methods of doing O_foo flag inheritance... but the
above is more interesting.
-dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
