Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Wed, Apr 13, 2005 at 11:14:10 +0200, Miklos Szeredi wrote: > > > There are uses for both. For example today I was updating the tar ball > > > which is used to create the var file system for a new chroot. I > > > certainly > > > want to see corretly setup owner/permissions when I look into that tar > > > ball using a FUSE fs... > > > > If I'm updating a var filesystem for a new chroot, I'd need the > > ability to chmod and chown things in that filesystem. Does that work > > as an ordinary user? > > Yes, within UML for example. That's a bad example. UML does in fact *NOT* invoke host kernel's chmod, because it has all the filesystem in a file. But the answer is yes anyway. It's up to the filesystem to check whether it is allowed. FUSE does not block it and if the actual userland driver does not protest either, it is possible. >[...] --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, Apr 12, 2005 at 21:08:25 +0200, Miklos Szeredi wrote: > > There was a thread a few months ago where file-as-directory was > > discussed extensively, after Namesys implemented it. That's where the > > conversation on detachable mount points originated AFAIR. It will > > probably happen at some point. > > > > A nice implemention of it in FUSE could push it along a bit :) > > Aren't there some assumptions in VFS that currently make this > impossible? I believe it's OK with VFS, but applications would be confused to death. Well, there really is one issue -- dentries have exactly one parent, so what do you do when opening a file with hardlinks as a directory? (In fact IIRC that is what lead to all the funny talk about mountpoints, since they don't have this limitation) --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, Apr 12, 2005 at 21:08:25 +0200, Miklos Szeredi wrote: There was a thread a few months ago where file-as-directory was discussed extensively, after Namesys implemented it. That's where the conversation on detachable mount points originated AFAIR. It will probably happen at some point. A nice implemention of it in FUSE could push it along a bit :) Aren't there some assumptions in VFS that currently make this impossible? I believe it's OK with VFS, but applications would be confused to death. Well, there really is one issue -- dentries have exactly one parent, so what do you do when opening a file with hardlinks as a directory? (In fact IIRC that is what lead to all the funny talk about mountpoints, since they don't have this limitation) --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Wed, Apr 13, 2005 at 11:14:10 +0200, Miklos Szeredi wrote: There are uses for both. For example today I was updating the tar ball which is used to create the var file system for a new chroot. I certainly want to see corretly setup owner/permissions when I look into that tar ball using a FUSE fs... If I'm updating a var filesystem for a new chroot, I'd need the ability to chmod and chown things in that filesystem. Does that work as an ordinary user? Yes, within UML for example. That's a bad example. UML does in fact *NOT* invoke host kernel's chmod, because it has all the filesystem in a file. But the answer is yes anyway. It's up to the filesystem to check whether it is allowed. FUSE does not block it and if the actual userland driver does not protest either, it is possible. [...] --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, Apr 12, 2005 at 17:13:03 +0100, Jamie Lokier wrote: > Miklos Szeredi wrote: > > > Note that NFS checks the permissions on _both_ the client and server, > > > for a reason. > > > > Does it? If I read the code correctly the client checks credentials > > supplied by the server (or cached). But the server does the actual > > checking of permissions. > > > > Am I missing something? > > Yes, for NFSv2, this test in nfs_permssion(): > > if (!NFS_PROTO(inode)->access) > goto out; > > And for either version of NFS, if the uid and gid are non-zero, and > the permission bits indicate that an access is permitted, then the > client does not consult the server for permission. ... but that clearly says that it checks the permissions on *either* cleint *or* server. Not all requests are passed to the server and there the client only checks the permission bits, even if the credentials are different than what was originally used to obtain the information. --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Mon, Apr 11, 2005 at 17:56:09 +0200, Miklos Szeredi wrote: > > Could you explain a little more? I don't see the point in denying > > access to root, but I also can't tell from your explanation whether you > > do or not. > > Fuse by default does. This can be disabled by one of two mount > options: "allow_other" and "allow_root". The former implies the > later. These mount options are only allowed for mounting by root, but > this can be relaxed with a configuration option. > > > If I mount a filesystem using ssh, I want to be able to "sudo cp > > foo.txt /etc" and not get an inexplicable permissions error. > > If you can do that sudo, you can also modify the configuration and use > one of the mount options. And that's as false as it can be! Ok, no sane admin would probably give out sudo permissions for cp, but other commands may make sense (perhaps setting some sysctl in /proc -- that needs fsuid=0 -- otherwise one could teach sudo to set euid, but not fsuid). And than the user would *NOT* be able to use those mount options. Anyway, why are the options not available to non-root? It's their filesystem, they should be allowed to set it up! > > > 4) Access should not be further restricted for the owner of the > > > mount, even if permission bits, uid or gid would suggest > > > otherwise > > > > Similar questions. > > This behavior can be disabled by the "default_permissions" mount > option (wich is not privileged, since it adds restrictions). A FUSE > filesystem mounted by root (and not for private purposes) would > normally be done with "allow_other,default_permissions". I'd hell lot prefer it the other way around. The user write bit is an accident counter-measure similarly to the root squashing. It needs to be split to two orthogonal options -- one to specify, whether all files are owned by the mounter or by whomever the filesystem says and another whether permissions are checked. --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Mon, Apr 11, 2005 at 17:56:09 +0200, Miklos Szeredi wrote: Could you explain a little more? I don't see the point in denying access to root, but I also can't tell from your explanation whether you do or not. Fuse by default does. This can be disabled by one of two mount options: allow_other and allow_root. The former implies the later. These mount options are only allowed for mounting by root, but this can be relaxed with a configuration option. If I mount a filesystem using ssh, I want to be able to sudo cp foo.txt /etc and not get an inexplicable permissions error. If you can do that sudo, you can also modify the configuration and use one of the mount options. And that's as false as it can be! Ok, no sane admin would probably give out sudo permissions for cp, but other commands may make sense (perhaps setting some sysctl in /proc -- that needs fsuid=0 -- otherwise one could teach sudo to set euid, but not fsuid). And than the user would *NOT* be able to use those mount options. Anyway, why are the options not available to non-root? It's their filesystem, they should be allowed to set it up! 4) Access should not be further restricted for the owner of the mount, even if permission bits, uid or gid would suggest otherwise Similar questions. This behavior can be disabled by the default_permissions mount option (wich is not privileged, since it adds restrictions). A FUSE filesystem mounted by root (and not for private purposes) would normally be done with allow_other,default_permissions. I'd hell lot prefer it the other way around. The user write bit is an accident counter-measure similarly to the root squashing. It needs to be split to two orthogonal options -- one to specify, whether all files are owned by the mounter or by whomever the filesystem says and another whether permissions are checked. --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, Apr 12, 2005 at 17:13:03 +0100, Jamie Lokier wrote: Miklos Szeredi wrote: Note that NFS checks the permissions on _both_ the client and server, for a reason. Does it? If I read the code correctly the client checks credentials supplied by the server (or cached). But the server does the actual checking of permissions. Am I missing something? Yes, for NFSv2, this test in nfs_permssion(): if (!NFS_PROTO(inode)-access) goto out; And for either version of NFS, if the uid and gid are non-zero, and the permission bits indicate that an access is permitted, then the client does not consult the server for permission. ... but that clearly says that it checks the permissions on *either* cleint *or* server. Not all requests are passed to the server and there the client only checks the permission bits, even if the credentials are different than what was originally used to obtain the information. --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Kernel SCM saga..
On Mon, Apr 11, 2005 at 04:56:06 +0200, Marcin Dalecki wrote: > > On 2005-04-11, at 04:26, Miles Bader wrote: > > >Marcin Dalecki <[EMAIL PROTECTED]> writes: > >>Better don't waste your time with looking at Arch. Stick with patches > >>you maintain by hand combined with some scripts containing a list of > >>apply commands and you should be still more productive then when using > >>Arch. > > > >Arch has its problems, but please lay off the uninformed flamebait (the > >"issues" you complain about are so utterly minor as to be laughable). > > I wish you a lot of laughter after replying to an already 3 days old > message, > which was my final on Arch. Marcin Dalecki <[EMAIL PROTECTED]> complained: > Arch isn't a sound example of software design. Quite contrary to the > random notes posted by it's author the following issues did strike me > the time I did evaluate it: > [...] I didn't comment on this first time, but I see I should have. *NONE* of the issues you complained about were issues of *DESIGN*. They were all issues of *ENGINEERING*. *ENGINEERING* issues can be fixed. One of the issues does not even exist any longer (the diff/patch one -- it now checks they are the right ones -- and in all other respects it is *exactly* the same as depending on a library) But what really matters here is the concept. Arch has a simple concept, that works well. Others have different concepts, that work well or almost well too (Darcs, Monotone). --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Kernel SCM saga..
On Mon, Apr 11, 2005 at 04:56:06 +0200, Marcin Dalecki wrote: On 2005-04-11, at 04:26, Miles Bader wrote: Marcin Dalecki [EMAIL PROTECTED] writes: Better don't waste your time with looking at Arch. Stick with patches you maintain by hand combined with some scripts containing a list of apply commands and you should be still more productive then when using Arch. Arch has its problems, but please lay off the uninformed flamebait (the issues you complain about are so utterly minor as to be laughable). I wish you a lot of laughter after replying to an already 3 days old message, which was my final on Arch. Marcin Dalecki [EMAIL PROTECTED] complained: Arch isn't a sound example of software design. Quite contrary to the random notes posted by it's author the following issues did strike me the time I did evaluate it: [...] I didn't comment on this first time, but I see I should have. *NONE* of the issues you complained about were issues of *DESIGN*. They were all issues of *ENGINEERING*. *ENGINEERING* issues can be fixed. One of the issues does not even exist any longer (the diff/patch one -- it now checks they are the right ones -- and in all other respects it is *exactly* the same as depending on a library) But what really matters here is the concept. Arch has a simple concept, that works well. Others have different concepts, that work well or almost well too (Darcs, Monotone). --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Kernel SCM saga..
On Sat, Apr 09, 2005 at 03:01:29 +0200, Marcin Dalecki wrote:
>
> On 2005-04-07, at 09:44, Jan Hudec wrote:
> >
> >I have looked at most systems currently available. I would suggest
> >following for closer look on:
> >
> >1) GNU Arch/Bazaar. They use the same archive format, simple, have the
> > concepts right. It may need some scripts or add ons. When Bazaar-NG
> > is ready, it will be able to read the GNU Arch/Bazaar archives so
> > switching should be easy.
>
> Arch isn't a sound example of software design. Quite contrary to the
I actually _do_ agree with you. I like Arch, but it's user interface
certainly is broken and some parts of it would sure needs some redesign.
> random notes posted by it's author the following issues did strike me
> the time I did evaluate it:
>
> The application (tla) claims to have "intuitive" command names. However
> I didn't see that as given. Most of them where difficult to remember
> and appeared to be just infantile. I stopped looking further after I
> saw:
>
> tla my-id instead of: tla user-id or oeven tla set id ...
>
> tla make-archive instead of tla init
In this case, tla init would be a lot *worse*, because there are two
different things to initialize -- the archive and the tree. But
init-archive would be a little better, for consistency.
> tla my-default-archive [EMAIL PROTECTED]
This one is kinda broken. Even in concept it is.
> No more "My Compuer" please...
>
> Repository addressing requires you to use informally defined
> very elaborated and typing error prone conventions:
>
> mkdir ~/{archives}
*NO*. Usng this is name is STRONGLY recommended *AGAINST*. Tom once used
it in the example or in some of his archive and people started doing it,
but it's a compelete bogosity and it is not required anywhere.
> tla make-archive [EMAIL PROTECTED]
> ~/{archives}/2005-VersionPatrol
>
> You notice the requirement for two commands to accomplish a single task
> already well denoted by the second command? There is more of the same
> at quite a few places when you try to use it. You notice the triple
> zero it didn't catch?
I sure do. But the folks writing Bazaar are gradually fixing these.
There is a lot of them and it's not that long since they started, so
they did not fix all of them yey, but I think they eventually will.
> As an added bonus it relies on the applications named by accident
> patch and diff and installed on the host in question as well as few
> other as well to
> operate.
No. The build process actually checks that the diff and patch
applications are actually the GNU Diff and GNU Patch in sufficiently
recent version. It's was not always the case, but now it does.
> Better don't waste your time with looking at Arch. Stick with patches
> you maintain by hand combined with some scripts containing a list of
> apply commands
> and you should be still more productive then when using Arch.
I don't agree with you. Using Arch is more productive (eg. because it
does merges), but certainly one could do a lot better than Arch does.
---
Jan 'Bulb' Hudec <[EMAIL
PROTECTED]>
signature.asc
Description: Digital signature
Re: Kernel SCM saga..
On Sat, Apr 09, 2005 at 03:01:29 +0200, Marcin Dalecki wrote:
On 2005-04-07, at 09:44, Jan Hudec wrote:
I have looked at most systems currently available. I would suggest
following for closer look on:
1) GNU Arch/Bazaar. They use the same archive format, simple, have the
concepts right. It may need some scripts or add ons. When Bazaar-NG
is ready, it will be able to read the GNU Arch/Bazaar archives so
switching should be easy.
Arch isn't a sound example of software design. Quite contrary to the
I actually _do_ agree with you. I like Arch, but it's user interface
certainly is broken and some parts of it would sure needs some redesign.
random notes posted by it's author the following issues did strike me
the time I did evaluate it:
The application (tla) claims to have intuitive command names. However
I didn't see that as given. Most of them where difficult to remember
and appeared to be just infantile. I stopped looking further after I
saw:
tla my-id instead of: tla user-id or oeven tla set id ...
tla make-archive instead of tla init
In this case, tla init would be a lot *worse*, because there are two
different things to initialize -- the archive and the tree. But
init-archive would be a little better, for consistency.
tla my-default-archive [EMAIL PROTECTED]
This one is kinda broken. Even in concept it is.
No more My Compuer please...
Repository addressing requires you to use informally defined
very elaborated and typing error prone conventions:
mkdir ~/{archives}
*NO*. Usng this is name is STRONGLY recommended *AGAINST*. Tom once used
it in the example or in some of his archive and people started doing it,
but it's a compelete bogosity and it is not required anywhere.
tla make-archive [EMAIL PROTECTED]
~/{archives}/2005-VersionPatrol
You notice the requirement for two commands to accomplish a single task
already well denoted by the second command? There is more of the same
at quite a few places when you try to use it. You notice the triple
zero it didn't catch?
I sure do. But the folks writing Bazaar are gradually fixing these.
There is a lot of them and it's not that long since they started, so
they did not fix all of them yey, but I think they eventually will.
As an added bonus it relies on the applications named by accident
patch and diff and installed on the host in question as well as few
other as well to
operate.
No. The build process actually checks that the diff and patch
applications are actually the GNU Diff and GNU Patch in sufficiently
recent version. It's was not always the case, but now it does.
Better don't waste your time with looking at Arch. Stick with patches
you maintain by hand combined with some scripts containing a list of
apply commands
and you should be still more productive then when using Arch.
I don't agree with you. Using Arch is more productive (eg. because it
does merges), but certainly one could do a lot better than Arch does.
---
Jan 'Bulb' Hudec [EMAIL
PROTECTED]
signature.asc
Description: Digital signature
Re: Kernel SCM saga..
On Wed, Apr 06, 2005 at 08:42:08 -0700, Linus Torvalds wrote: > PS. Don't bother telling me about subversion. If you must, start reading > up on "monotone". That seems to be the most viable alternative, but don't > pester the developers so much that they don't get any work done. They are > already aware of my problems ;) I have looked at most systems currently available. I would suggest following for closer look on: 1) GNU Arch/Bazaar. They use the same archive format, simple, have the concepts right. It may need some scripts or add ons. When Bazaar-NG is ready, it will be able to read the GNU Arch/Bazaar archives so switching should be easy. 2) SVK. True, it is built on subversion, but adds all the distributed features necessary. It keeps mirror of the repository localy (but can mirror only some branches), but BitKeeper did that too. It just hit 1.0beta1, but the development is progressing rapidly. There was a post about ability to track changeset dependencies lately on their mailing-list. I have looked at Monotone too, of course, but I did not find any way for doing cherry-picking (ie. skipping some changes and pulling others) in it and I feel it will need more rework of the meta-data before it is possible. As for the sqlite backend, I'd not consider that a problem. --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Kernel SCM saga..
On Wed, Apr 06, 2005 at 08:42:08 -0700, Linus Torvalds wrote: PS. Don't bother telling me about subversion. If you must, start reading up on monotone. That seems to be the most viable alternative, but don't pester the developers so much that they don't get any work done. They are already aware of my problems ;) I have looked at most systems currently available. I would suggest following for closer look on: 1) GNU Arch/Bazaar. They use the same archive format, simple, have the concepts right. It may need some scripts or add ons. When Bazaar-NG is ready, it will be able to read the GNU Arch/Bazaar archives so switching should be easy. 2) SVK. True, it is built on subversion, but adds all the distributed features necessary. It keeps mirror of the repository localy (but can mirror only some branches), but BitKeeper did that too. It just hit 1.0beta1, but the development is progressing rapidly. There was a post about ability to track changeset dependencies lately on their mailing-list. I have looked at Monotone too, of course, but I did not find any way for doing cherry-picking (ie. skipping some changes and pulling others) in it and I feel it will need more rework of the meta-data before it is possible. As for the sqlite backend, I'd not consider that a problem. --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Writing data > PAGESIZE into kernel with proc fs
On Wed, Mar 09, 2005 at 11:26:30 +0100, Weber Matthias wrote:
> On Tue, Mar 08, 2005 at 20:05:42 +0100, Weber Matthias wrote:
> >> is there any chance to signal an EOF when writing data to kernel via proc
> >> fs? >> Actually if the length of data is N*PAGE_SIZE it seems not to be
> >> detectable.
> >> I followed up the "struct file" but haven't found anything that helped...
>
> > End-of-file is signified by closing the file. As usual.
>
> Having only this struct describing an proc entry, i have no idea on how to
> detect when the file is closed. For this i expect to register a callback
> function but where and how?
>
> struct proc_dir_entry {
> unsigned int low_ino;
> unsigned short namelen;
> const char *name;
> mode_t mode;
> nlink_t nlink;
> uid_t uid;
> gid_t gid;
> unsigned long size;
> struct inode_operations * proc_iops;
> struct file_operations * proc_fops;
^^^
When it comes to that, you can always prepare your won file operations
instead of the default ones (that use read_proc and write_proc) below
and turn the proc entry into whatever you want.
> get_info_t *get_info;
> struct module *owner;
> struct proc_dir_entry *next, *parent, *subdir;
> void *data;
> read_proc_t *read_proc;
> write_proc_t *write_proc;
> atomic_t count; /* use count */
> int deleted;/* delete flag */
> };
The simple way of working with proc files is to have userland just fill
in the buffer and process that buffer when you need to, not when the
userland sends the data. So you just take the "data" buffer when you
need it.
When you need something more fancy, you simply create your own
proc_fops. That has read and write functions, where you need to take
care of the offset yourself, but you can treat each open separately
(open is called when userland process opens your proc entry and IIRC
fput or release or something like that when it closes it (you do NOT
want "close" -- that might be called more than once for one open)), turn
it into character-device-alike, implement ioctl, implement select/poll
on your entry and other fancy stuff.
Of course, you can copy the default proc_fops and only implement the
ones you actualy need different.
---
Jan 'Bulb' Hudec <[EMAIL
PROTECTED]>
signature.asc
Description: Digital signature
Re: Writing data PAGESIZE into kernel with proc fs
On Wed, Mar 09, 2005 at 11:26:30 +0100, Weber Matthias wrote:
On Tue, Mar 08, 2005 at 20:05:42 +0100, Weber Matthias wrote:
is there any chance to signal an EOF when writing data to kernel via proc
fs? Actually if the length of data is N*PAGE_SIZE it seems not to be
detectable.
I followed up the struct file but haven't found anything that helped...
End-of-file is signified by closing the file. As usual.
Having only this struct describing an proc entry, i have no idea on how to
detect when the file is closed. For this i expect to register a callback
function but where and how?
struct proc_dir_entry {
unsigned int low_ino;
unsigned short namelen;
const char *name;
mode_t mode;
nlink_t nlink;
uid_t uid;
gid_t gid;
unsigned long size;
struct inode_operations * proc_iops;
struct file_operations * proc_fops;
^^^
When it comes to that, you can always prepare your won file operations
instead of the default ones (that use read_proc and write_proc) below
and turn the proc entry into whatever you want.
get_info_t *get_info;
struct module *owner;
struct proc_dir_entry *next, *parent, *subdir;
void *data;
read_proc_t *read_proc;
write_proc_t *write_proc;
atomic_t count; /* use count */
int deleted;/* delete flag */
};
The simple way of working with proc files is to have userland just fill
in the buffer and process that buffer when you need to, not when the
userland sends the data. So you just take the data buffer when you
need it.
When you need something more fancy, you simply create your own
proc_fops. That has read and write functions, where you need to take
care of the offset yourself, but you can treat each open separately
(open is called when userland process opens your proc entry and IIRC
fput or release or something like that when it closes it (you do NOT
want close -- that might be called more than once for one open)), turn
it into character-device-alike, implement ioctl, implement select/poll
on your entry and other fancy stuff.
Of course, you can copy the default proc_fops and only implement the
ones you actualy need different.
---
Jan 'Bulb' Hudec [EMAIL
PROTECTED]
signature.asc
Description: Digital signature
Re: Writing data > PAGESIZE into kernel with proc fs
On Tue, Mar 08, 2005 at 20:05:42 +0100, Weber Matthias wrote: > is there any chance to signal an EOF when writing data to kernel via proc fs? > Actually if the length of data is N*PAGE_SIZE it seems not to be detectable. > I followed up the "struct file" but haven't found anything that helped... End-of-file is signified by closing the file. As usual. --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Writing data PAGESIZE into kernel with proc fs
On Tue, Mar 08, 2005 at 20:05:42 +0100, Weber Matthias wrote: is there any chance to signal an EOF when writing data to kernel via proc fs? Actually if the length of data is N*PAGE_SIZE it seems not to be detectable. I followed up the struct file but haven't found anything that helped... End-of-file is signified by closing the file. As usual. --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: userspace vs. kernelspace address
On Fri, Jan 28, 2005 at 20:23:55 -0800, Om wrote: > On Fri, Jan 28, 2005 at 01:40:51PM -0800, Rock Gordon wrote: > > Hi everbody, > > > > Thanks for your replies. > > > > However I think my copy_to_user and copy_from_user are > > failing since the kernel-mode thread is copying data > > into another process's address space, and I am not > > sure how to do this. Do the get_fs() and set_fs() > > combinations let you do that? If not, then how do I do > My idea is on kernel thread is limited. But I think it is not possible to > any userspace address from any kernel thread because they do not have access > to it. Their proc_struct->mm field is empty. Right. You can't access any user-space from kernel thread, because it does not have any. > I am not sure whether set_fs and get_fs help in this case. Sure it can. set_fs(KERNEL_DS) sets things so, that if you pass kernel address to copy_to/from_user, it will silently accept it and copy to/from there. --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: userspace vs. kernelspace address
On Fri, Jan 28, 2005 at 20:23:55 -0800, Om wrote: On Fri, Jan 28, 2005 at 01:40:51PM -0800, Rock Gordon wrote: Hi everbody, Thanks for your replies. However I think my copy_to_user and copy_from_user are failing since the kernel-mode thread is copying data into another process's address space, and I am not sure how to do this. Do the get_fs() and set_fs() combinations let you do that? If not, then how do I do My idea is on kernel thread is limited. But I think it is not possible to any userspace address from any kernel thread because they do not have access to it. Their proc_struct-mm field is empty. Right. You can't access any user-space from kernel thread, because it does not have any. I am not sure whether set_fs and get_fs help in this case. Sure it can. set_fs(KERNEL_DS) sets things so, that if you pass kernel address to copy_to/from_user, it will silently accept it and copy to/from there. --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Re: Process creating]
On Wed, Jun 27, 2001 at 12:35:13AM -0600, Blesson Paul wrote: > 1: P1 and P2 have different physical areas of memory. This is how > protection works. > > 2: Why do they need to share the same memory? You can have your second > process > communicate with your first process through IPC. > > 3: Linux supports threading if you include the thread library, and use the > appropriate > threading process calls. > > Another thing you can do is have a common space on the hard drive. It's not > as fast as RAM, > but it's one solution. As to 1 (and 3), if you clone the processes (using the __clone - advanced version of fork), you can specify what the processes should share. Including memory. Thus you can also have threads (that share everything but stack) even without a thread library (libpthread actualy does just that, but it has some conveniece stuff like locks). As of 2, avoid using ipc, especialy the sysv one - it's rather kind of crap (IMHO). --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> - 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: A signal fairy tale
On Fri, Jun 29, 2001 at 01:26:29AM -0700, Christopher Smith wrote: > At 10:59 AM 6/28/2001 -0400, Dan Maas wrote: > >life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation > >into queued, information-carrying siginfo signals just shows how badly we > >need a more robust event model... (what would truly kick butt is a unified > >interface that could deliver everything from fd events to AIO completions to > >semaphore/msgqueue events, etc, with explicit binding between event queues > >and threads). > > I guess this is my thinking: it's really not that much of a stretch to make > signals behave like GetMessage(). Indeed, sigopen() brings them > sufficiently close. By doing this, you DO provide this unified interface > for all the different types of events you described which works much like > GetMessage(). So, but adding a couple of syscalls you avoid having to > implement a whole new set of API's for doing AIO, semaphores, msgqueues, etc. Wouldn't recv/recvfrom/recvmsg suffice? I think they could do the trick. More covenience functions can than be derived in userland library. You still have one type of events per descriptor, but you can combine with poll in userspace library. --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> - 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: Alan Cox quote? (was: Re: accounting for threads)
Hello, > I am happy that processes in Linux are so marvelous. Linux does not need > a decent POSIX threads implementation because the same functionality can > be achived with processes. Do what you like, you write the kernel code. > I could write my soft using fork special fetaures in Linux. > But I want it to be portable. If threads in linux are so bad, it is bad > luck for me. I will go slow. It its the only portable way todo afordable > shared memory threading without filling your program of shm-. AFAIK, there is a POSIX thread library (libpthread) for Linux, that wraps clone calls in a way portable to other unices. It uses processes (with memory sharing) from kernel point of view, but should look like POSIX threads from application point of view. --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> - 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: Alan Cox quote? (was: Re: accounting for threads)
Hello, I am happy that processes in Linux are so marvelous. Linux does not need a decent POSIX threads implementation because the same functionality can be achived with processes. Do what you like, you write the kernel code. I could write my soft using fork special fetaures in Linux. But I want it to be portable. If threads in linux are so bad, it is bad luck for me. I will go slow. It its the only portable way todo afordable shared memory threading without filling your program of shm-. AFAIK, there is a POSIX thread library (libpthread) for Linux, that wraps clone calls in a way portable to other unices. It uses processes (with memory sharing) from kernel point of view, but should look like POSIX threads from application point of view. --- Jan 'Bulb' Hudec [EMAIL PROTECTED] - 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: A signal fairy tale
On Fri, Jun 29, 2001 at 01:26:29AM -0700, Christopher Smith wrote: At 10:59 AM 6/28/2001 -0400, Dan Maas wrote: life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation into queued, information-carrying siginfo signals just shows how badly we need a more robust event model... (what would truly kick butt is a unified interface that could deliver everything from fd events to AIO completions to semaphore/msgqueue events, etc, with explicit binding between event queues and threads). I guess this is my thinking: it's really not that much of a stretch to make signals behave like GetMessage(). Indeed, sigopen() brings them sufficiently close. By doing this, you DO provide this unified interface for all the different types of events you described which works much like GetMessage(). So, but adding a couple of syscalls you avoid having to implement a whole new set of API's for doing AIO, semaphores, msgqueues, etc. Wouldn't recv/recvfrom/recvmsg suffice? I think they could do the trick. More covenience functions can than be derived in userland library. You still have one type of events per descriptor, but you can combine with poll in userspace library. --- Jan 'Bulb' Hudec [EMAIL PROTECTED] - 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: [Re: Process creating]
On Wed, Jun 27, 2001 at 12:35:13AM -0600, Blesson Paul wrote: 1: P1 and P2 have different physical areas of memory. This is how protection works. 2: Why do they need to share the same memory? You can have your second process communicate with your first process through IPC. 3: Linux supports threading if you include the thread library, and use the appropriate threading process calls. Another thing you can do is have a common space on the hard drive. It's not as fast as RAM, but it's one solution. As to 1 (and 3), if you clone the processes (using the __clone - advanced version of fork), you can specify what the processes should share. Including memory. Thus you can also have threads (that share everything but stack) even without a thread library (libpthread actualy does just that, but it has some conveniece stuff like locks). As of 2, avoid using ipc, especialy the sysv one - it's rather kind of crap (IMHO). --- Jan 'Bulb' Hudec [EMAIL PROTECTED] - 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: RPC vs Socket
> I am in the way of building a new remote file system.
> Presently I decided to use sockets for remote communication. Lately I
> understood that RPC is used in coda and nfs file systems(is it so). I want to
> know the fessibility in using RPC in the new file system.
Both seem to have pros and cons. RPC should be easier to write (especialy the
server side), but it performs bad with UDP on slow links. (NFS did not work on
115200 serial line because of too many dropped packets - TCP flow control too
badly needed in such cases). Or can linux do RPC over TCP?
For puropose of shool excercise the work saved with RPC might be tha main argument.
- Jan Hudec `Bulb' <[EMAIL PROTECTED]>
-
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: RPC vs Socket
I am in the way of building a new remote file system. Presently I decided to use sockets for remote communication. Lately I understood that RPC is used in coda and nfs file systems(is it so). I want to know the fessibility in using RPC in the new file system. Both seem to have pros and cons. RPC should be easier to write (especialy the server side), but it performs bad with UDP on slow links. (NFS did not work on 115200 serial line because of too many dropped packets - TCP flow control too badly needed in such cases). Or can linux do RPC over TCP? For puropose of shool excercise the work saved with RPC might be tha main argument. - Jan Hudec `Bulb' [EMAIL PROTECTED] - 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: your mail
> So it seems that PnP finds the card, but the connections (or even the
> forced values) to the sb module fail. Back when this was a single
> processor machine, but still running 2.4 kernel, a windoze
> installation found the SB at the listed interface parameters.
>
>
> Anyone have a solution?
>
> Same problem without modules.conf settings, valid version of mod
> utilities, a web search did not help,...
I had a similar problem with different card (Gravi Usltrasound PnP).
The solution turned out to be to avoid dma 1 channel. May be some BIOSes
or ISA chipsets got the 8-bit dma channels handling wrong, but I really
don't know. Btw: for me 2.2.x autodetected right, 2.4.x need explicit setting.
- Jan Hudec `Bulb' <[EMAIL PROTECTED]>
-
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: Client receives TCP packets but does not ACK
> > TCP is NOT a guaranteed protocol -- you can't just blast data from one
> port
> > to another and expect it to work.
>
> Isn't it? Are you really sure about that? I thought UDP was the
> not-guaranteed-one and TCP was the one guaranting that all data reaches the
> other end in order and all. Please enlighten me.
It's "hlaf guaranteed." It guarantees, that if data are delivered to the
reciever, all data sent before already arived and in correct order. But it's
not guaranteed that data succesuly writen on 1 end actualy arived unless the
connection was correctly shutdown and closed.
Btw: can the aplication somehow ask the tcp/ip stack what was actualy acked?
(ie. how many bytes were acked).
- Jan Hudec `Bulb' <[EMAIL PROTECTED]>
-
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: Client receives TCP packets but does not ACK
TCP is NOT a guaranteed protocol -- you can't just blast data from one port to another and expect it to work. Isn't it? Are you really sure about that? I thought UDP was the not-guaranteed-one and TCP was the one guaranting that all data reaches the other end in order and all. Please enlighten me. It's hlaf guaranteed. It guarantees, that if data are delivered to the reciever, all data sent before already arived and in correct order. But it's not guaranteed that data succesuly writen on 1 end actualy arived unless the connection was correctly shutdown and closed. Btw: can the aplication somehow ask the tcp/ip stack what was actualy acked? (ie. how many bytes were acked). - Jan Hudec `Bulb' [EMAIL PROTECTED] - 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: your mail
So it seems that PnP finds the card, but the connections (or even the forced values) to the sb module fail. Back when this was a single processor machine, but still running 2.4 kernel, a windoze installation found the SB at the listed interface parameters. Anyone have a solution? Same problem without modules.conf settings, valid version of mod utilities, a web search did not help,... I had a similar problem with different card (Gravi Usltrasound PnP). The solution turned out to be to avoid dma 1 channel. May be some BIOSes or ISA chipsets got the 8-bit dma channels handling wrong, but I really don't know. Btw: for me 2.2.x autodetected right, 2.4.x need explicit setting. - Jan Hudec `Bulb' [EMAIL PROTECTED] - 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/
ifconfig freezes in 2.4.5
Hi, When I compiled and booted 2.4.5, the machine got stuck in ifconfig lo 127.0.0.1 (SysRq still worked, ^C did not seem to). I tried to strace it. Last thing strace managed to write was: ioctl(4, 0x8914 (no comma, not including the trird argument). I tried to switch of some compile-time parameters I changed from 2.4.4, but problem persisted. After reversing 2.4.5 patch and recompiling the kernel (using exactly the same config), the problem dispaeared. I include the .config used. I'll try to gen any aother information you might consider some use, but currently have no idea what it might be. --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> - 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/
ifconfig freezes in 2.4.5
Hi, When I compiled and booted 2.4.5, the machine got stuck in ifconfig lo 127.0.0.1 (SysRq still worked, ^C did not seem to). I tried to strace it. Last thing strace managed to write was: ioctl(4, 0x8914 (no comma, not including the trird argument). I tried to switch of some compile-time parameters I changed from 2.4.4, but problem persisted. After reversing 2.4.5 patch and recompiling the kernel (using exactly the same config), the problem dispaeared. I include the .config used. I'll try to gen any aother information you might consider some use, but currently have no idea what it might be. --- Jan 'Bulb' Hudec [EMAIL PROTECTED] - 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: question: permission checking for network filesystem
> > open mode has 4 bits: read, write, append and execute.
>
> I hope "write" and "append" interact nicely, giving 4 choices.
>
> 00 no write
> 01 append only
> 10 overwrite only (no file size change)
> 11 full write, append, truncate, etc.
... that's 1) Wrong 2) I need 4 bits ... that's 16 choices.
It's wrong because append is specified in addition to write (for open syscall).
- Jan Hudec `Bulb' <[EMAIL PROTECTED]>
-
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: question: permission checking for network filesystem
open mode has 4 bits: read, write, append and execute. I hope write and append interact nicely, giving 4 choices. 00 no write 01 append only 10 overwrite only (no file size change) 11 full write, append, truncate, etc. ... that's 1) Wrong 2) I need 4 bits ... that's 16 choices. It's wrong because append is specified in addition to write (for open syscall). - Jan Hudec `Bulb' [EMAIL PROTECTED] - 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: question: permission checking for network filesystem
> You can write lookup so that it always succeeds and returns dummy inode > without sending anything and do all the work in open & inode operations. It'd be great if I could. But I can't. First, the inode data are checked by some vfs functions before driver is called (this being the bigest problem: if (S_ISDIR(inode->i_mode) && (flag & FMODE_WRITE)) goto exit; - I think these checks could be, perhaps better, done by having right i_fop->open on different types of inodes) It could be done partialy (ie. returning dummy data for all but the last inode in path_walk) if path_walk passed LOOKUP_CONTINUE to i_ops->lookup (it's passed to d_ops->d_revalidate so NFS can avoid revalidating inodes on the way). I think adding this flag to i_ops->lookup won't break anything and make path_walk more self-consistent. (Also passing all flags from path_walk might help some optimization). > > exclusivity of write versus execute is the other > > (can't be workaround). > > MAP_DENYWRITE is used for this. If somebody is mapping file with > MAP_DENYWRITE, lock it on server. Write locking does not depend on exec, > and it is bad to expect that it may be used only in exec. There is one problem - I don't get to get/deny_write_permission functions. They operate on i_writecount and don't call the driver. MAP_DENYWRITE must be solved by mandatory write-lock on the file... I still think it's better to check permission in open ( Anyway, is there any reason file->f_ops->open shouldn't have the information inode->i_ops->permission had? Even if I unite opening for read and for exec, permissions still have to be queried and permission is definitely no good place. Lookup might do, but it might not do on other operating systems. -------- - Jan Hudec `Bulb' <[EMAIL PROTECTED]> - 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: question: permission checking for network filesystem
You can write lookup so that it always succeeds and returns dummy inode without sending anything and do all the work in open inode operations. It'd be great if I could. But I can't. First, the inode data are checked by some vfs functions before driver is called (this being the bigest problem: if (S_ISDIR(inode-i_mode) (flag FMODE_WRITE)) goto exit; - I think these checks could be, perhaps better, done by having right i_fop-open on different types of inodes) It could be done partialy (ie. returning dummy data for all but the last inode in path_walk) if path_walk passed LOOKUP_CONTINUE to i_ops-lookup (it's passed to d_ops-d_revalidate so NFS can avoid revalidating inodes on the way). I think adding this flag to i_ops-lookup won't break anything and make path_walk more self-consistent. (Also passing all flags from path_walk might help some optimization). exclusivity of write versus execute is the other (can't be workaround). MAP_DENYWRITE is used for this. If somebody is mapping file with MAP_DENYWRITE, lock it on server. Write locking does not depend on exec, and it is bad to expect that it may be used only in exec. There is one problem - I don't get to get/deny_write_permission functions. They operate on i_writecount and don't call the driver. MAP_DENYWRITE must be solved by mandatory write-lock on the file... I still think it's better to check permission in open ( Anyway, is there any reason file-f_ops-open shouldn't have the information inode-i_ops-permission had? Even if I unite opening for read and for exec, permissions still have to be queried and permission is definitely no good place. Lookup might do, but it might not do on other operating systems. - Jan Hudec `Bulb' [EMAIL PROTECTED] - 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: question: permission checking for network filesystem
Hi, > > I'm trying to impelemnt a lightweight network filesystem and ran into > > trouble implementing lookup, permissions and open. > > > > The protocol requires me to specify open mode in it's open command. The > > open mode has 4 bits: read, write, append and execute. But I can't tell > > There are two ways how you can implement security in network file system: > > 1. you expect that users have not root access on the client machine and > you check permissions on client (like in NFS). In this case the 'x' and > 'r' bits are checked on the client and you don't have to care about them > in protocol. > > 2. you expect that users have root access on client machine and you check > permissions on the server. In this case users can read executed files > anyway. Neither. If user has acces to the protocol, he certainly can do some things more. But you definitely can't check permissions on client. The trouble is, that this limits access policy on server to what the clients understand. Checking on server on the other hand allows server to implement any access policy (even using 3rd party software) without having clients to know the details (sou they can be kept stupid and simple = fast and managable) > If you are checking permissions on server, read/execute have no security > meaning. Client can send 'execute' request and then store data somwhere to > file. Opening for 'execute' won't enhance your security. Agree, but it will improve behavior. Or speed, rather. Otherwise open would take 3(!) roundtrips (instead of two - now lookup can't be get rid of) - lookup, permission and open. The protocol can do all three in one request. The problem is I can't tell the 3 calls from VFS belong together. > > Could anyone see a solution other than adding a flags to open mode (say > > O_EXEC and O_EXEC_LIB), that would be added to the dentry_open in open_exec > > and sys_uselib? I don't like the idea of pathing vfs for this. > > Send always 'open for read' and ignore 'open for execute'. Won't work for many reasons. Correct error code is one (could be removed by pre-checking permission), exclusivity of write versus execute is the other (can't be workaround). Checking permissions with lookup might be possible, but won't solve the exec/write exclusion and put more trust on the client, than is desireable. > And also remember that having file without read permission and with > execute permission makes sence only for suid programs. User can read the > file via /proc//mem or attach debugger to the process... It does not make sence (x without r). But it surely makes sence to have a program with read but without exec permission (though it can be made to run). -------- - Jan Hudec `Bulb' <[EMAIL PROTECTED]> - 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: question: permission checking for network filesystem
Hi, I'm trying to impelemnt a lightweight network filesystem and ran into trouble implementing lookup, permissions and open. The protocol requires me to specify open mode in it's open command. The open mode has 4 bits: read, write, append and execute. But I can't tell There are two ways how you can implement security in network file system: 1. you expect that users have not root access on the client machine and you check permissions on client (like in NFS). In this case the 'x' and 'r' bits are checked on the client and you don't have to care about them in protocol. 2. you expect that users have root access on client machine and you check permissions on the server. In this case users can read executed files anyway. Neither. If user has acces to the protocol, he certainly can do some things more. But you definitely can't check permissions on client. The trouble is, that this limits access policy on server to what the clients understand. Checking on server on the other hand allows server to implement any access policy (even using 3rd party software) without having clients to know the details (sou they can be kept stupid and simple = fast and managable) If you are checking permissions on server, read/execute have no security meaning. Client can send 'execute' request and then store data somwhere to file. Opening for 'execute' won't enhance your security. Agree, but it will improve behavior. Or speed, rather. Otherwise open would take 3(!) roundtrips (instead of two - now lookup can't be get rid of) - lookup, permission and open. The protocol can do all three in one request. The problem is I can't tell the 3 calls from VFS belong together. Could anyone see a solution other than adding a flags to open mode (say O_EXEC and O_EXEC_LIB), that would be added to the dentry_open in open_exec and sys_uselib? I don't like the idea of pathing vfs for this. Send always 'open for read' and ignore 'open for execute'. Won't work for many reasons. Correct error code is one (could be removed by pre-checking permission), exclusivity of write versus execute is the other (can't be workaround). Checking permissions with lookup might be possible, but won't solve the exec/write exclusion and put more trust on the client, than is desireable. And also remember that having file without read permission and with execute permission makes sence only for suid programs. User can read the file via /proc/pid/mem or attach debugger to the process... It does not make sence (x without r). But it surely makes sence to have a program with read but without exec permission (though it can be made to run). - Jan Hudec `Bulb' [EMAIL PROTECTED] - 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/
question: permission checking for network filesystem
Hi,
I'm trying to impelemnt a lightweight network filesystem and ran into
trouble implementing lookup, permissions and open.
The protocol requires me to specify open mode in it's open command. The
open mode has 4 bits: read, write, append and execute. But I can't tell
execution from read in file_operations->open. I could send the open command
from the inode_operations->permission, but this does not solve the problem,
as I can't find weather to count the new file descriptor as reader or
executer (I have to know that when closing the file).
The server always checks permission on the actual request, so I can't open
the file for reading, when it should be open for execution.
Could anyone see a solution other than adding a flags to open mode (say
O_EXEC and O_EXEC_LIB), that would be added to the dentry_open in open_exec
and sys_uselib? I don't like the idea of pathing vfs for this.
If it has to be patched, what kind of patch has a chance to get into 2.4
series kernel?
There is another thing with lookup. The protocol allows looking up and
opening a file in one command. Unfortunately there are some file-type
checks between i_ops->lookup and f_ops->open that force me to wait on the
lookup to finish before I can open. I think these checks could be done by
simply having the f_ops->open set correctly (thinks like not opening
directory for write). But I do not expect these to change before 2.5,
right?
Thanks in advance.
Bulb
- Jan Hudec `Bulb' <[EMAIL PROTECTED]>
-
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/
question: permission checking for network filesystem
Hi, I'm trying to impelemnt a lightweight network filesystem and ran into trouble implementing lookup, permissions and open. The protocol requires me to specify open mode in it's open command. The open mode has 4 bits: read, write, append and execute. But I can't tell execution from read in file_operations-open. I could send the open command from the inode_operations-permission, but this does not solve the problem, as I can't find weather to count the new file descriptor as reader or executer (I have to know that when closing the file). The server always checks permission on the actual request, so I can't open the file for reading, when it should be open for execution. Could anyone see a solution other than adding a flags to open mode (say O_EXEC and O_EXEC_LIB), that would be added to the dentry_open in open_exec and sys_uselib? I don't like the idea of pathing vfs for this. If it has to be patched, what kind of patch has a chance to get into 2.4 series kernel? There is another thing with lookup. The protocol allows looking up and opening a file in one command. Unfortunately there are some file-type checks between i_ops-lookup and f_ops-open that force me to wait on the lookup to finish before I can open. I think these checks could be done by simply having the f_ops-open set correctly (thinks like not opening directory for write). But I do not expect these to change before 2.5, right? Thanks in advance. Bulb - Jan Hudec `Bulb' [EMAIL PROTECTED] - 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: Inodes
> Blesson Paul writes: > > > This is an another doubt related to VFS. I want to know > > wheather all files are assigned their inode number at the > > mounting time itself or inodes are assigned to files upon > > accessing only > > That would depend on what type of filesystem you use. > For ext2, inode numbers are assigned at file creation. > For vfat, inode numbers are assigned as needed, and > forgotten when not needed. I think using pointers to inode structures as inode numbers might be an optimal solution. Since inode structure is long, it can even be shifted few bits left if some special numbers are needed. Uniqueness check should be added for 64-bit platforms, but it should work without (kernel memory is not large enough for the nuber to wrap). Bulb - 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: Inodes
Blesson Paul writes: This is an another doubt related to VFS. I want to know wheather all files are assigned their inode number at the mounting time itself or inodes are assigned to files upon accessing only That would depend on what type of filesystem you use. For ext2, inode numbers are assigned at file creation. For vfat, inode numbers are assigned as needed, and forgotten when not needed. I think using pointers to inode structures as inode numbers might be an optimal solution. Since inode structure is long, it can even be shifted few bits left if some special numbers are needed. Uniqueness check should be added for 64-bit platforms, but it should work without (kernel memory is not large enough for the nuber to wrap). Bulb - 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/
