Re: [RFC] FUSE permission modell (Was: fuse review bits)
> > Well the sanity check on the "server" side is always enforced. You > > can't "trick" sftp or ftp to not check permissions. So checking on > > the "client" side too (where the fuse daemon is running) makes no > > sense, does it? > > That argument doesn't make much sense to me. But we're at the end of > my useful contributions to this discussion; I'm going to be quiet now > and hope some folks who know more about filesystems have more useful > responses. I'm sorry if this isn't clear enough. My explanatory powers are not very strong, so please bear with me. Imagine an sftp session. You list the files on the remote server. You want download a file for which there are very limited permission (e.g. only readable to owner). You don't _know_ if you are the owner since the uid on the file does not ring any bells, but you still try, since you want that file badly. And you succeed. Would it make sense if the sftp client would try to interpret the uid/gid/permission on each file? Obviously not. The same is true for the case when you mount an sshfs. Since you entered your password (or have a passwordless login to the server) you are authorized to browse the files on the server, but only with the capabilities you have there as a user. The server does the authorization. The same is true for an NFS mount btw. It's not the client that checks the permissions. So do you see why I argue in favor of having an option _not_ to check permissions on the client by the kernel? Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
> I think that would be _much_ nicer implemented as a mount which is > invisible to other users, rather than one which causes the admin's > scripts to spew error messages. Spew is a strong word. It'll get a single EACCES at the mountpoint. The same is true for directories not accessible by 'nobody' under an NFS mount exported with root squash. > Is the namespace mechanism at all suitable for that? It is certainly the right tool for this. However currently private namespaces are quite limited. The only sane usage I can think of is that before mounting the user starts a shell with CLONE_NS, and does the mount in this. However all the other programs he already has running (editor, browser, desktop environment) won't be able to access the mount. Shared subtrees and more support in userspace tools is needed before private namespaces can become really useful. > It would also be nice to generalise and have virtual filesystems which > are able to present different views to different users. Can FUSE do > that already - is the userspace part told which user is doing each > operation? Yes. > With that, the desire for virtual filesystems which cannot be read > by your sysadmin (by accident) is easy to satisfy - and that kind of > mechanism would probably be acceptable to all. The problem is that this way the responsibility goes to the userspace program, which can't be trusted. Either the kernel has to enforce that uid/gid on each file are set to the mount owner, or the kernel has to enforce that no other user has access to the mountpoint. Some policy _must_ be kept in kernel. I think both these policies have valid uses, so I wouldn't want to limit FUSE to a single one. Hmm? Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Mon, Apr 11, 2005 at 09:56:29PM +0200, Miklos Szeredi wrote: > Well the sanity check on the "server" side is always enforced. You > can't "trick" sftp or ftp to not check permissions. So checking on > the "client" side too (where the fuse daemon is running) makes no > sense, does it? That argument doesn't make much sense to me. But we're at the end of my useful contributions to this discussion; I'm going to be quiet now and hope some folks who know more about filesystems have more useful responses. -- Daniel Jacobowitz CodeSourcery, LLC - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > That is exactly the intended effect. If I'm at my work machine (where > I'm not an admin unfortunately) and I mount my home machine with sshfs > (because FUSE is installed fortunately :), then I bloody well don't > want the sysadmin or some automated script of his to go mucking under > the mountpoint. I think that would be _much_ nicer implemented as a mount which is invisible to other users, rather than one which causes the admin's scripts to spew error messages. Is the namespace mechanism at all suitable for that? It would also be nice to generalise and have virtual filesystems which are able to present different views to different users. Can FUSE do that already - is the userspace part told which user is doing each operation? With that, the desire for virtual filesystems which cannot be read by your sysadmin (by accident) is easy to satisfy - and that kind of mechanism would probably be acceptable to all. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
> > > Root squashing is actually a much less obnoxious restriction. It means > > > that local uid 0 doesn't automatically correspond to remote uid 0. > > > > I don't agree that it's less obnoxious. Root squashing and a > > restricted directory (-rwx--) would have exactly the same affect: > > root is denied all access. > > That's considerably less obnoxious, because such directories are > comparatively rare; most files, root can still read. There are still > a couple unintuitive cases where root has less privelege than a > particular non-root user, of course. But your model gives root > normally fewer privileges than the user that mounted th e FS. That is exactly the intended effect. If I'm at my work machine (where I'm not an admin unfortunately) and I mount my home machine with sshfs (because FUSE is installed fortunately :), then I bloody well don't want the sysadmin or some automated script of his to go mucking under the mountpoint. > > > But why does the kernel need to know anything about this? Why can't > > > the userspace library present the permissions appropriately to the > > > kernel? > > > > That is exactly what you should do if you use the default_permissions > > options. You set the file mode, and the kernel checks the permission. > > So why not make default_permissions a feature of the userspace? I don't understand. The userspace can't enforce the permissions. That can only be done by the kernel. The "default_permissions" option tells the kernel to enforce permissions based on file mode. If the option is missing, then the kernel does not enforce those permissions. > > > I'm going to be pretty confused if I see a mode 666 file that I > > > can't even read. So will various programs. > > > > How would you get such I file? I don't understand. > > The permissions exposed by the FUSE layer apparently don't correspond > to what local users can do with them. That's the problem here. It may > be that I'm completely misunderstanding you - but from what you've > described, the userspace daemon can mark a file's permissions as 666, > and then with allow_other and allow_root off no one else will be able > to read it, despite those permissions. Other users won't be able to read even the attributes, so I don't see it as a problem. It will be a special "no go" directory for anyone except the mount owner. > > > Except for the allow_root bits, I think that having userspace handle > > > the issue entirely would cover both objections. > > > > If I want to allow unprivileged users to be able to mount their > > filesystems, then handling everything in userspace is not an option. > > For example if you could mount a filesystem in which files have > > user=root instead of your own user ID, you could probably confuse some > > applications running as root, and cause information leak. That's > > exactly why allow_root and allow_other are disabled for normal users. > > > > The only safe option that I can imagine is that the kernel will reset > > the user and group fields of the file attributes. This would again > > require a kernel option, but would be far less useful IMO. > > I think we've got a boundary problem here. You are exposing some > arbitrary, user-supplied values in the permissions, and then performing > sanity checks at access time; I'm suggesting performing the sanity > checking on the other side, when the permissions are supplied to the > kernel by the daemon. Well the sanity check on the "server" side is always enforced. You can't "trick" sftp or ftp to not check permissions. So checking on the "client" side too (where the fuse daemon is running) makes no sense, does it? > Why would it be less useful to show files that have been "created" by a > user as owned by that user? Or files that the user has requested no > other users be able to write as unwritable by group/other? Sure, it > makes your tarfs a little less mapped onto the tar file. But that's > one of the recurring objections to implementing archivers as > filesystems: the ownership in the archive is _not_ relevant to the > mounted copy. So this objection is now dealt with. Is that a problem? Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
> > 1) User must not be able to modify files or directories in a way > > which he otherwise could not do (e.g. mount a filesystem over > > /bin) > > > > 2) Suid and device semantics should be disabled within the mount > > > > 3) No other user should have access to files under the mount, not > > even root[5] > > Why? I can see plenty of uses where I want a filesystem generated by > one user to be accessible by other users. That policy should not be > hard-coded into the kernel. It might be an option. It is. > > 4) Access should not be further restricted for the owner of the > > mount, even if permission bits, uid or gid would suggest > > otherwise > > Why? Surely you want to prevent writing to files which don't have the > writable bit set? A filesystem may also create append-only files - > and all users including the mount owner should be bound by that. You are right. This is indeed possible optionally. I'm saying that maybe the filesystem owner _does_ _not_ want any more restrictions despite the attributes. Consider a tar file in which there is a file owned by 'root' and having permissions (-rw---). If you have read access to the tar file, you can obviously actually read the file inside the tar file despite it's permissions. > > 5) As much of the available information should be exported via the > > filesystem as possible > > This is the root of the conflict. You are trying to overload the > permission bits and uid/gid to mean something different than they > normally do. Yes. > While it's convenient to see some "remote" information such as the > uid/gid in a tar file, are you sure it's a good idea to break the unix > permissions model - which will break some programs? (For example, try > editing a file with the broken semantics in an editor which checks the > uid/gid of the file against the current user). Why would a program do that? In fact I've not come accross such a program yet, so this is pretty theoretical. On the other hand even if such a program existed, the filesystem could still have an option to change uid/gid/mode on all files to something 'standard' (like uid/gid/umask options for stupid filesystems). > For most virtual filesystems, the "remote" information does not map to > uid/gid in a particularly natural way anyway. Tar archives of local disk? Sshfs to server with which you have shared passwd files? These are not made up examples. > So it seems odd to want to break the unix permissions model just so > that a small _subset_ of virtual filesystems can use stat() as a way > to get a bit of information out, when other virtual filesystems > (e.g. webdavfs) can't put meaningful information in there, and would > benefit from normal unix permissions instead. But where there's no meaningful information, you don't need to make it up. What I'm proposing doesn't limit the filesystem in any way. There's an option to leave permission checking to the kernel, then all you need to worry about is setting the mode bits. That is perfectly OK. > > 1) Only allow mount over a directory for which the user has write > > access (and is not sticky) > > Seems good - but why not sticky? Mounting a user filesystem in > /tmp/user-xxx/my-mount-point seems not unreasonable - provided the > administrator can delete the directory (which is possible with > detachable mount points). Yes. The only thing you're not allowed is to mount on /tmp, for obvious reasons :) > > 2) Use nosuid,nodev mount options > > Of course. Ideally, make sure they appear to be set in /proc/mounts. They are in fact set by the fusermount userspace utility. So there's no extra kernel magic involved. > (root (or equivalent) should be able to create virtual filesystems > without these options, but probably they should be set by default even > for root, and clearable using suid,dev). That is exactly how it works. > > 3) In permission method of FUSE kernel module compare fsuid against > > mounting user's ID, and return EACCES if they are not equal. > > Bad. How do I, user A, then create a virtual filesystem which I want > user B to be able to access? But together with the option to set arbitary uid/gid on the files within your mounts this could be abused, I think. So either this or that. If someone really needs this I can implement another option. > > 4) The filesystem daemon does not run with elevated permissions. > > The kernel doesn't check file more in the permission method. > > I like the idea that the fs daemon doesn't need elevated permissions. > > > 5) The filesystem daemon is free to fill in all file attributes to > > any (sane) value, and the kernel won't modify these. > > Dangerous, because an administrative program might actually trust the > attributes to mean what they normally mean in the unix permissions model. Yes, I agree with you fully. This is exactly why other users including root are not allowed access to t
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Mon, Apr 11, 2005 at 09:10:46PM +0200, Miklos Szeredi wrote: > > Root squashing is actually a much less obnoxious restriction. It means > > that local uid 0 doesn't automatically correspond to remote uid 0. > > I don't agree that it's less obnoxious. Root squashing and a > restricted directory (-rwx--) would have exactly the same affect: > root is denied all access. That's considerably less obnoxious, because such directories are comparatively rare; most files, root can still read. There are still a couple unintuitive cases where root has less privelege than a particular non-root user, of course. But your model gives root normally fewer privileges than the user that mounted th e FS. > > But why does the kernel need to know anything about this? Why can't > > the userspace library present the permissions appropriately to the > > kernel? > > That is exactly what you should do if you use the default_permissions > options. You set the file mode, and the kernel checks the permission. So why not make default_permissions a feature of the userspace? > > I'm going to be pretty confused if I see a mode 666 file that I > > can't even read. So will various programs. > > How would you get such I file? I don't understand. The permissions exposed by the FUSE layer apparently don't correspond to what local users can do with them. That's the problem here. It may be that I'm completely misunderstanding you - but from what you've described, the userspace daemon can mark a file's permissions as 666, and then with allow_other and allow_root off no one else will be able to read it, despite those permissions. > > Except for the allow_root bits, I think that having userspace handle > > the issue entirely would cover both objections. > > If I want to allow unprivileged users to be able to mount their > filesystems, then handling everything in userspace is not an option. > For example if you could mount a filesystem in which files have > user=root instead of your own user ID, you could probably confuse some > applications running as root, and cause information leak. That's > exactly why allow_root and allow_other are disabled for normal users. > > The only safe option that I can imagine is that the kernel will reset > the user and group fields of the file attributes. This would again > require a kernel option, but would be far less useful IMO. I think we've got a boundary problem here. You are exposing some arbitrary, user-supplied values in the permissions, and then performing sanity checks at access time; I'm suggesting performing the sanity checking on the other side, when the permissions are supplied to the kernel by the daemon. Why would it be less useful to show files that have been "created" by a user as owned by that user? Or files that the user has requested no other users be able to write as unwritable by group/other? Sure, it makes your tarfs a little less mapped onto the tar file. But that's one of the recurring objections to implementing archivers as filesystems: the ownership in the archive is _not_ relevant to the mounted copy. -- Daniel Jacobowitz CodeSourcery, LLC - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
> > > > 3) No other user should have access to files under the mount, not > > > > even root[5] > > > > > > > [5] Obviously root cannot be restricted, but accidental access to > > > > private data is still a good idea. E.g. root squashing by NFS servers > > > > has a similar affect. > > > > > > 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. > > So the behavior that Cristoph was objecting to here is in fact > configurable? Christoph was not objcting to lack of choice, rather the opposite. He would like to have only the "allow_other" behavior. > > > I don't really see the point of this restriction, anyway. Could you > > > explain why this shouldn't be a matter of policy, and kept out of the > > > kernel? Have the userspace file servers default to putting restrictive > > > permissions on mounts unless requested otherwise. > > > > That's an option. However you can't restrict root that way, and you > > need an extra directory, since permissions on the mountpoint are > > ignored after the mount. > > No, you need the userspace daemon to set the permissions on the root > directory of the new mount restrictively. What am I missing? You are basically right. This would conflict slightly with 5) in that the attributes of the root would be lost. > > Restricting root is needed, so that a sysadmin won't accidently go > > into a user's private mount (e.g. sshfs to some machine to which the > > sysadmin otherwise has no access). Root can still gain access by > > doing 'su me', but at least he will have a bad conscience. This is > > not such a stupid idea as it first sounds IMO, and by default all NFS > > servers exhibit a similar behavior (root squashing). > > Root squashing is actually a much less obnoxious restriction. It means > that local uid 0 doesn't automatically correspond to remote uid 0. I don't agree that it's less obnoxious. Root squashing and a restricted directory (-rwx--) would have exactly the same affect: root is denied all access. > > > > 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". > > But why does the kernel need to know anything about this? Why can't > the userspace library present the permissions appropriately to the > kernel? That is exactly what you should do if you use the default_permissions options. You set the file mode, and the kernel checks the permission. > I'm going to be pretty confused if I see a mode 666 file that I > can't even read. So will various programs. How would you get such I file? I don't understand. > Except for the allow_root bits, I think that having userspace handle > the issue entirely would cover both objections. If I want to allow unprivileged users to be able to mount their filesystems, then handling everything in userspace is not an option. For example if you could mount a filesystem in which files have user=root instead of your own user ID, you could probably confuse some applications running as root, and cause information leak. That's exactly why allow_root and allow_other are disabled for normal users. The only safe option that I can imagine is that the kernel will reset the user and group fields of the file attributes. This would again require a kernel option, but would be far less useful IMO. Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Mon, Apr 11, 2005 at 07:22:57PM +0100, Jamie Lokier wrote: > > 1) Only allow mount over a directory for which the user has write > > access (and is not sticky) > > Seems good - but why not sticky? Mounting a user filesystem in > /tmp/user-xxx/my-mount-point seems not unreasonable - provided the > administrator can delete the directory (which is possible with > detachable mount points). Because then they could mount over /tmp. "and (is not sticky || is owned by the user)" may be more appropriate. -- Daniel Jacobowitz CodeSourcery, LLC - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > 1) User must not be able to modify files or directories in a way > which he otherwise could not do (e.g. mount a filesystem over > /bin) > > 2) Suid and device semantics should be disabled within the mount > > 3) No other user should have access to files under the mount, not > even root[5] Why? I can see plenty of uses where I want a filesystem generated by one user to be accessible by other users. That policy should not be hard-coded into the kernel. It might be an option. > 4) Access should not be further restricted for the owner of the > mount, even if permission bits, uid or gid would suggest > otherwise Why? Surely you want to prevent writing to files which don't have the writable bit set? A filesystem may also create append-only files - and all users including the mount owner should be bound by that. > 5) As much of the available information should be exported via the > filesystem as possible This is the root of the conflict. You are trying to overload the permission bits and uid/gid to mean something different than they normally do. While it's convenient to see some "remote" information such as the uid/gid in a tar file, are you sure it's a good idea to break the unix permissions model - which will break some programs? (For example, try editing a file with the broken semantics in an editor which checks the uid/gid of the file against the current user). For most virtual filesystems, the "remote" information does not map to uid/gid in a particularly natural way anyway. So it seems odd to want to break the unix permissions model just so that a small _subset_ of virtual filesystems can use stat() as a way to get a bit of information out, when other virtual filesystems (e.g. webdavfs) can't put meaningful information in there, and would benefit from normal unix permissions instead. > 1) Only allow mount over a directory for which the user has write > access (and is not sticky) Seems good - but why not sticky? Mounting a user filesystem in /tmp/user-xxx/my-mount-point seems not unreasonable - provided the administrator can delete the directory (which is possible with detachable mount points). > 2) Use nosuid,nodev mount options Of course. Ideally, make sure they appear to be set in /proc/mounts. (root (or equivalent) should be able to create virtual filesystems without these options, but probably they should be set by default even for root, and clearable using suid,dev). > 3) In permission method of FUSE kernel module compare fsuid against > mounting user's ID, and return EACCES if they are not equal. Bad. How do I, user A, then create a virtual filesystem which I want user B to be able to access? > 4) The filesystem daemon does not run with elevated permissions. > The kernel doesn't check file more in the permission method. I like the idea that the fs daemon doesn't need elevated permissions. > 5) The filesystem daemon is free to fill in all file attributes to > any (sane) value, and the kernel won't modify these. Dangerous, because an administrative program might actually trust the attributes to mean what they normally mean in the unix permissions model. > The debated part is 3) and 4), namely that normal permission checking > based on file mode is bypassed, and the mounting user has full > permission to all files, while other users have none. > > This feature has been in FUSE from the start and thus has been very > well tested in real world scenarios. Also I have thought a lot about > how this could pose any kind of security threat, and as yet found no > such possiblity. Ok, but why do you prevent the useful behaviour of allowing access to other users, when I want that? For example, I might export my current project's database as a filesystem that I _want_ other users to be able to read. > Despite this Christoph feels this behavior is unacceptable for a > filesystem, and wants me to remove this feature before merging FUSE > into mainline. I try to be open to ideas, but also feel strongly that > this is the Right Way, so I won't give up easily. I agree with Christoph. It is a huge deviation from the unix permissions model -- and it seems to prevent some useful applications of FUSE so it's not clear why you want it. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Mon, Apr 11, 2005 at 05:56:09PM +0200, Miklos Szeredi wrote: > > > 3) No other user should have access to files under the mount, not > > > even root[5] > > > > > [5] Obviously root cannot be restricted, but accidental access to > > > private data is still a good idea. E.g. root squashing by NFS servers > > > has a similar affect. > > > > 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. So the behavior that Cristoph was objecting to here is in fact configurable? > > I don't really see the point of this restriction, anyway. Could you > > explain why this shouldn't be a matter of policy, and kept out of the > > kernel? Have the userspace file servers default to putting restrictive > > permissions on mounts unless requested otherwise. > > That's an option. However you can't restrict root that way, and you > need an extra directory, since permissions on the mountpoint are > ignored after the mount. No, you need the userspace daemon to set the permissions on the root directory of the new mount restrictively. What am I missing? > Restricting root is needed, so that a sysadmin won't accidently go > into a user's private mount (e.g. sshfs to some machine to which the > sysadmin otherwise has no access). Root can still gain access by > doing 'su me', but at least he will have a bad conscience. This is > not such a stupid idea as it first sounds IMO, and by default all NFS > servers exhibit a similar behavior (root squashing). Root squashing is actually a much less obnoxious restriction. It means that local uid 0 doesn't automatically correspond to remote uid 0. > > > 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". But why does the kernel need to know anything about this? Why can't the userspace library present the permissions appropriately to the kernel? I'm going to be pretty confused if I see a mode 666 file that I can't even read. So will various programs. Except for the allow_root bits, I think that having userspace handle the issue entirely would cover both objections. > Does this answer your questions? More or less. -- Daniel Jacobowitz CodeSourcery, LLC - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] autofs4 - expiring filesystem from under process
==> Regarding [PATCH 1/3] autofs4 - expiring filesystem from under process;
[EMAIL PROTECTED] adds:
raven> autofs4-2.6.12-rc1-mm4-wait-order.patch
raven> It's possible for an event wait request to arive before the event
raven> requestor. If this happens the daemon never gets notified and autofs
raven> hangs.
I'm not sure I understand your problem description. Could you please
elaborate on the set of circumstances that lead to this?
Could also please explain how the following is handled:
expire process runs and issues AUTOFS_EXPIRE_MULTI, which sets
AUTOFS_INF_EXPIRING in flags. While the expire is in progress, another
process access the directory in question, causing a call to
try_to_fill_dentry. try_to_fill_dentry sees the AUTOFS_INF_EXPIRING flag
is set, and so calls autofs4_wait with notify set to NFY_NONE. However,
when we take the wq sem, we find that the expire has finished, and thus
create a new wq entry. Because NFY_NONE is set, we don't tell the daemon.
So how will this process ever get woken up?
Thanks!
Jeff
raven> Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
raven> --- linux-2.6.12-rc1-mm4/fs/autofs4/waitq.c.wait-order 2005-04-03
12:30:14.0 +0800
raven> +++ linux-2.6.12-rc1-mm4/fs/autofs4/waitq.c 2005-04-03
12:31:57.0 +0800
raven> @@ -210,17 +210,8 @@ int autofs4_wait(struct autofs_sb_info *
wq-> len = len;
wq-> status = -EINTR; /* Status return if interrupted */
raven> atomic_set(&wq->wait_ctr, 2);
raven> +atomic_set(&wq->notified, 1);
raven> up(&sbi->wq_sem);
raven> -
raven> -DPRINTK("new wait id = 0x%08lx, name = %.*s, nfy=%d",
raven> -(unsigned long) wq->wait_queue_token, wq->len,
wq->name, notify);
raven> -/* autofs4_notify_daemon() may block */
raven> -if (notify != NFY_NONE) {
raven> -autofs4_notify_daemon(sbi,wq,
raven> -notify == NFY_MOUNT ?
raven> - autofs_ptype_missing :
raven> -
autofs_ptype_expire_multi);
raven> -}
raven> } else {
raven> atomic_inc(&wq->wait_ctr);
raven> up(&sbi->wq_sem);
raven> @@ -229,6 +220,17 @@ int autofs4_wait(struct autofs_sb_info *
raven> (unsigned long) wq->wait_queue_token, wq->len,
wq->name, notify);
raven> }
raven> +if (notify != NFY_NONE && atomic_dec_and_test(&wq->notified)) {
raven> +int type = (notify == NFY_MOUNT ?
raven> +autofs_ptype_missing :
autofs_ptype_expire_multi);
raven> +
raven> +DPRINTK(("new wait id = 0x%08lx, name = %.*s, nfy=%d\n",
raven> +(unsigned long) wq->wait_queue_token, wq->len,
wq->name, notify));
raven> +
raven> +/* autofs4_notify_daemon() may block */
raven> +autofs4_notify_daemon(sbi, wq, type);
raven> +}
raven> +
raven> /* wq->name is NULL if and only if the lock is already released
*/
raven> if ( sbi->catatonic ) {
raven> --- linux-2.6.12-rc1-mm4/fs/autofs4/autofs_i.h.wait-order
2005-04-03 12:30:24.0 +0800
raven> +++ linux-2.6.12-rc1-mm4/fs/autofs4/autofs_i.h 2005-04-03
12:30:46.0 +0800
raven> @@ -84,6 +84,7 @@ struct autofs_wait_queue {
raven> char *name;
raven> /* This is for status reporting upon return */
raven> int status;
raven> +atomic_t notified;
raven> atomic_t wait_ctr;
raven> };
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
> > 3) No other user should have access to files under the mount, not > > even root[5] > > > [5] Obviously root cannot be restricted, but accidental access to > > private data is still a good idea. E.g. root squashing by NFS servers > > has a similar affect. > > 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. > I don't really see the point of this restriction, anyway. Could you > explain why this shouldn't be a matter of policy, and kept out of the > kernel? Have the userspace file servers default to putting restrictive > permissions on mounts unless requested otherwise. That's an option. However you can't restrict root that way, and you need an extra directory, since permissions on the mountpoint are ignored after the mount. Restricting root is needed, so that a sysadmin won't accidently go into a user's private mount (e.g. sshfs to some machine to which the sysadmin otherwise has no access). Root can still gain access by doing 'su me', but at least he will have a bad conscience. This is not such a stupid idea as it first sounds IMO, and by default all NFS servers exhibit a similar behavior (root squashing). > > 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". Does this answer your questions? Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Mon, Apr 11, 2005 at 04:43:32PM +0200, Miklos Szeredi wrote: > 3) No other user should have access to files under the mount, not > even root[5] > [5] Obviously root cannot be restricted, but accidental access to > private data is still a good idea. E.g. root squashing by NFS servers > has a similar affect. 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. 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. I don't really see the point of this restriction, anyway. Could you explain why this shouldn't be a matter of policy, and kept out of the kernel? Have the userspace file servers default to putting restrictive permissions on mounts unless requested otherwise. I can think of plenty of uses for this. > 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. -- Daniel Jacobowitz CodeSourcery, LLC - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Important update - autofs 4.1.4 release
On Sun, 10 Apr 2005 [EMAIL PROTECTED] wrote: Hi all, Here is autofs 4.1.4. There were a couple of mistakes in the release. The kernel patches have been updated as there were some obvious errors in them. An error in patching of the Debian portion of the init script was corrected. I've uploaded corrected versions along with a MD5SUMS file of checksums for people to verify against. The new upload has a timestamp of 11-Apr-2005 06:21-59. If you downloaded anything before this, sorry, you'll need to get the updated files. Ian - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Important update - autofs4 - updated module build kit and kernel patches
On Sun, 10 Apr 2005 [EMAIL PROTECTED] wrote: Hi all, I have updated the autofs4 kernel module build kit (kernel 2.4) and kernel patches (2.4 and 2.6). There were a couple of mistakes in the release. The kernel patches have been updated as there were some obvious errors in them. I've uploaded corrected versions along with a MD5SUM file of checksums for people to verify against. The new upload has a timestamp of 11-Apr-2005 06:21-59. If you downloaded anything before this, sorry, you'll need to get the updated files. Ian - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] semi-trivial patches
On Mon, 11 Apr 2005, Denis Vlasenko wrote: On Monday 11 April 2005 12:14, Ian Kent wrote: I remember applying several of your patches to do with this some time ago. On my development machine (an Ultra 2), the autofs daemon failed completely when trying to log. I mailed you asking about it but received no answer. I decided to return to it on next non-beta. This is what I've found: Crash was caused by me erroneously using syslog() instead of vsyslog(). (I didn't test logging to syslog back then, and bug slipped through). Are you able to help merging them when I get to it? Sure. Also please find attached patches which implement running in foreground and stderr logging. Saved em. Will get to them later. I really, really want to fix the direct mounts so I'm going to spend some time on that before I get into merging the enhancements I have. If I could just get 4.1.4 out without those silly errors Ian - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] FUSE permission modell (Was: fuse review bits)
We're having a bit of a disagreement with Christoph Hellwig about the way FUSE does (or should do) permission checking. Comments (either way) are appreciated. Here's my side of the story: FUSE (filesystem in userspace) is designed to allow mounting an FS by non-privileged users (it can also be used in the traditional way, but that is uncontroversial and I'm not going to detail it here). The philosophy behind this is that sometimes it's very convenient if a program can have a filesystem as it's _output_. Examples are: - tar, zip, rar, etc[1] filesystem - ftp[2], ssh[3], etc filesystem - cvs[4], svn, etc filesystem The common theme is that what you usually perform with some specialized command can equally well (or sometimes better) be performed with all the generic tools there are for file searching, viewing, etc. For example, the ftp and sftp commands actually give you a simulated filesystem with a very limited shell (some variants have improved the "simulation" by adding filename completion, etc). With FUSE you can have the real thing and use your favourite tools on remote or archived files. I think this fits in very well with the "everything is a file" UNIX philosophy. To allow this to work in the most convenient and secure way the following must be satisfied: 1) User must not be able to modify files or directories in a way which he otherwise could not do (e.g. mount a filesystem over /bin) 2) Suid and device semantics should be disabled within the mount 3) No other user should have access to files under the mount, not even root[5] 4) Access should not be further restricted for the owner of the mount, even if permission bits, uid or gid would suggest otherwise 5) As much of the available information should be exported via the filesystem as possible These are solved by: 1) Only allow mount over a directory for which the user has write access (and is not sticky) 2) Use nosuid,nodev mount options 3) In permission method of FUSE kernel module compare fsuid against mounting user's ID, and return EACCES if they are not equal. 4) The filesystem daemon does not run with elevated permissions. The kernel doesn't check file more in the permission method. 5) The filesystem daemon is free to fill in all file attributes to any (sane) value, and the kernel won't modify these. The debated part is 3) and 4), namely that normal permission checking based on file mode is bypassed, and the mounting user has full permission to all files, while other users have none. This feature has been in FUSE from the start and thus has been very well tested in real world scenarios. Also I have thought a lot about how this could pose any kind of security threat, and as yet found no such possiblity. Despite this Christoph feels this behavior is unacceptable for a filesystem, and wants me to remove this feature before merging FUSE into mainline. I try to be open to ideas, but also feel strongly that this is the Right Way, so I won't give up easily. OK, open the flamethrowers! Miklos [1] http://www.inf.bme.hu/~mszeredi/avfs/ (CVS version required for FUSE support) [2] http://sourceforge.net/project/showfiles.php?group_id=121684&package_id=132803 [3] http://fuse.sourceforge.net/sshfs.html [4] http://cvsfs.sourceforge.net/ [5] Obviously root cannot be restricted, but accidental access to private data is still a good idea. E.g. root squashing by NFS servers has a similar affect. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] semi-trivial patches
On Monday 11 April 2005 12:14, Ian Kent wrote:
> I remember applying several of your patches to do with this some time ago.
> On my development machine (an Ultra 2), the autofs daemon failed
> completely when trying to log. I mailed you asking about it but received
> no answer.
I decided to return to it on next non-beta. This is what I've found:
Crash was caused by me erroneously using syslog() instead of vsyslog().
(I didn't test logging to syslog back then, and bug slipped through).
> Are you able to help merging them when I get to it?
Sure.
Also please find attached patches which implement
running in foreground and stderr logging.
Both logging to syslog and to stderr work for me now.
--
vda
diff -urpN autofs-4.1.4.d.close/daemon/automount.c autofs-4.1.4.e.foreground/daemon/automount.c
--- autofs-4.1.4.d.close/daemon/automount.c Mon Apr 11 10:42:20 2005
+++ autofs-4.1.4.e.foreground/daemon/automount.c Mon Apr 11 11:07:56 2005
@@ -60,6 +60,7 @@ static int submount = 0;
int do_verbose = 0; /* Verbose feedback option */
int do_debug = 0; /* Enable full debug output */
+int daemonize = 1; /* Shall we daemonize? */
sigset_t ready_sigs; /* signals only accepted in ST_READY */
sigset_t lock_sigs; /* signals blocked for locking */
@@ -1282,7 +1283,7 @@ static void become_daemon(void)
chdir("/");
/* Detach from foreground process */
- if (!submount) {
+ if (!submount && daemonize) {
pid = fork();
if (pid > 0)
exit(0);
@@ -1382,7 +1383,19 @@ static unsigned long getnumopt(char *str
static void usage(void)
{
- fprintf(stderr, "Usage: %s [options] path map_type [args...]\n", program);
+ fprintf(stderr,
+ "Usage: %s [options] path map_type [args...]\n"
+ " -h --help this text\n"
+ " -p --pid-file f write process id to file f\n"
+ " -t --timeout n auto-unmount in n seconds (0-disable)\n"
+ " -f --foreground do not daemonize\n"
+ " -v --verbose be verbose\n"
+ " -d --debug be even more verbose\n"
+ " -V --version print version and exit\n"
+ /* " -g --ghost \n" */
+ /* " --submount \n" */
+ , program
+ );
}
static void setup_signals(__sighandler_t event_handler, __sighandler_t cld_handler)
@@ -1669,6 +1682,7 @@ int main(int argc, char *argv[])
{"help", 0, 0, 'h'},
{"pid-file", 1, 0, 'p'},
{"timeout", 1, 0, 't'},
+ {"foreground", 0, 0, 'f'},
{"verbose", 0, 0, 'v'},
{"debug", 0, 0, 'd'},
{"version", 0, 0, 'V'},
@@ -1686,7 +1700,7 @@ int main(int argc, char *argv[])
ap.dir_created = 0; /* We haven't created the main directory yet */
opterr = 0;
- while ((opt = getopt_long(argc, argv, "+hp:t:vdVg", long_options, NULL)) != EOF) {
+ while ((opt = getopt_long(argc, argv, "+hp:t:fvdVg", long_options, NULL)) != EOF) {
switch (opt) {
case 'h':
usage();
@@ -1698,6 +1712,10 @@ int main(int argc, char *argv[])
case 't':
ap.exp_timeout = getnumopt(optarg, opt);
+ break;
+
+ case 'f':
+ daemonize = 0;
break;
case 'v':
diff -urpN autofs-4.1.4.e.foreground/daemon/automount.c autofs-4.1.4.f.stderr/daemon/automount.c
--- autofs-4.1.4.e.foreground/daemon/automount.c Mon Apr 11 11:07:56 2005
+++ autofs-4.1.4.f.stderr/daemon/automount.c Mon Apr 11 14:39:45 2005
@@ -39,7 +39,7 @@
#include
#ifndef NDEBUG
-#define assert(x) do { if (!(x)) { syslog(LOG_CRIT, __FILE__ ":%d: assertion failed: " #x, __LINE__); } } while(0)
+#define assert(x) do { if (!(x)) { crit(__FILE__ ":%d: assertion failed: " #x, __LINE__); } } while(0)
#else
#define assert(x) do { } while(0)
#endif
@@ -61,6 +61,7 @@ static int submount = 0;
int do_verbose = 0; /* Verbose feedback option */
int do_debug = 0; /* Enable full debug output */
int daemonize = 1; /* Shall we daemonize? */
+int log_stderr = 0; /* Use stderr instead of syslog? */
sigset_t ready_sigs; /* signals only accepted in ST_READY */
sigset_t lock_sigs; /* signals blocked for locking */
@@ -160,7 +161,7 @@ static int umount_ent(const char *root,
umount_ok = 1;
if (umount_ok || is_smbfs) {
- rv = spawnll(LOG_DEBUG,
+ rv = spawnll(debug,
PATH_UMOUNT, PATH_UMOUNT, path_buf, NULL);
}
}
@@ -314,13 +315,13 @@ static int do_umount_autofs(void)
struct stat st;
int ret;
- rv = spawnll(LOG_DEBUG,
+ rv = spawnll(debug,
PATH_UMOUNT, PATH_UMOUNT, ap.path, NULL);
if (rv & MTAB_NOTUPDATED) {
info("umount %s succeeded: "
"mtab not updated, retrying to clean",
ap.path);
- rv = spawnll(LOG_DEBUG,
+ rv = spawnll(debug,
PATH_UMOUNT, PATH_UMOUNT, ap.path, NULL);
}
ret = stat(ap.path, &st);
@@ -450,7 +451,7 @@ static int mount_autofs(char *path)
}
our_name[len] = '\0';
- if (spawnll(LOG_DEBUG, PATH_MOUNT, PATH_MOUNT,
+ if (spawnll(debug, PATH_MOUNT, PATH_MOUNT,
"-t", "autofs", "-o", options, our_name, path, NULL) != 0) {
crit("failed to mount autofs path %s", ap.path);
rmdir_path(ap.path);
@@ -1020,7 +1021,7 @@ static int handle_packet_missing(const s
pid_t f;
struct pending_mount *
Re: [PATCH] semi-trivial patches
On Mon, 11 Apr 2005, Denis Vlasenko wrote: > On Sunday 10 April 2005 16:38, [EMAIL PROTECTED] wrote: > > > > Hi all, > > > > Here is autofs 4.1.4. > > Please find three patches attached. Good to see your persistent in keeping your patches upto date. I'll work through this soon as I can fix my mistakes in the 4.1.4 release. > > b.exec.patch makes it possible to rely on PATH > when exec'ing mount etc. If one wants to do this, he will > need to run configure like this: > OUNT="mount" \ > UMOUNT="umount" \ > E2FSCK="fsck.ext2" \ > E3FSCK="fsck.ext3" \ > ./configure > but at least one wouldn't need to hack C source for that to work > as expected (.i.e., to search for binaries in the PATH). > 'Classic' automount would be unaffected since it uses /abs/path/names, > and exec..p() does not search PATH in this case. > > c.msg.patch removes usage of %m in messages (this can't work for > non-syslog directed messages). I need this for pending --stderr patch. > Also it removes tons of stray newlines. > > d.close.patch fixes obscure bug when we can close one of standard > descriptors. > > Was run tested before, rediffed against 4.1.4 and compile tested. > > Please apply. I remember applying several of your patches to do with this some time ago. On my development machine (an Ultra 2), the autofs daemon failed completely when trying to log. I mailed you asking about it but received no answer. Are you able to help merging them when I get to it? Ian - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] autofs4 - expiring filesystem from under process
On Mon, 11 Apr 2005, Andrew Morton wrote:
> [EMAIL PROTECTED] wrote:
> >
> > static inline int autofs4_ispending(struct dentry *dentry)
> >{
> > struct autofs_info *inf = autofs4_dentry_ino(dentry);
> > + int pending;
> >
> > - return (dentry->d_flags & DCACHE_AUTOFS_PENDING) ||
> > - (inf != NULL && inf->flags & AUTOFS_INF_EXPIRING);
> > + if (dentry->d_flags & DCACHE_AUTOFS_PENDING)
> > + return 1;
> > +
> > + if (inf) {
> > + spin_lock(&inf->sbi->fs_lock);
> > + pending = inf->flags & AUTOFS_INF_EXPIRING;
> > + spin_unlock(&inf->sbi->fs_lock);
> > + }
> > +
> > + return pending;
>
> This can obviously return an uninitialised variable.
>
> Were these patches very well tested?
Minimal testing in 2.6.
There's been some fairly heavy use of the 2.4 version.
Never the less this is sloppy.
Perhaps you should reject them, rather than burn your time on it, and I
will resubmit when I've gone over them and sorted out the issues.
Ian
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] semi-trivial patches
On Sunday 10 April 2005 16:38, [EMAIL PROTECTED] wrote:
>
> Hi all,
>
> Here is autofs 4.1.4.
Please find three patches attached.
b.exec.patch makes it possible to rely on PATH
when exec'ing mount etc. If one wants to do this, he will
need to run configure like this:
OUNT="mount" \
UMOUNT="umount" \
E2FSCK="fsck.ext2" \
E3FSCK="fsck.ext3" \
./configure
but at least one wouldn't need to hack C source for that to work
as expected (.i.e., to search for binaries in the PATH).
'Classic' automount would be unaffected since it uses /abs/path/names,
and exec..p() does not search PATH in this case.
c.msg.patch removes usage of %m in messages (this can't work for
non-syslog directed messages). I need this for pending --stderr patch.
Also it removes tons of stray newlines.
d.close.patch fixes obscure bug when we can close one of standard
descriptors.
Was run tested before, rediffed against 4.1.4 and compile tested.
Please apply.
--
vda
diff -urpN autofs-4.1.4.a.orig/daemon/spawn.c autofs-4.1.4.b.exec/daemon/spawn.c
--- autofs-4.1.4.a.orig/daemon/spawn.c Thu Feb 10 14:56:53 2005
+++ autofs-4.1.4.b.exec/daemon/spawn.c Mon Apr 11 10:20:27 2005
@@ -228,8 +228,8 @@ static int do_spawn(int logpri, int use_
dup2(pipefd[1], STDERR_FILENO);
close(pipefd[1]);
- execv(prog, (char *const *) argv);
- _exit(255); /* execv() failed */
+ execvp(prog, (char *const *) argv);
+ _exit(255); /* exec() failed */
} else {
/* Careful here -- if we enable SIGCHLD yet we may not receive the
waitpid() at the end */
diff -urpN autofs-4.1.4.a.orig/modules/lookup_program.c autofs-4.1.4.b.exec/modules/lookup_program.c
--- autofs-4.1.4.a.orig/modules/lookup_program.c Fri Dec 31 08:30:09 2004
+++ autofs-4.1.4.b.exec/modules/lookup_program.c Mon Apr 11 10:20:27 2005
@@ -139,8 +139,8 @@ int lookup_mount(const char *root, const
dup2(epipefd[1], STDERR_FILENO);
close(pipefd[1]);
close(epipefd[1]);
- execl(ctxt->mapname, ctxt->mapname, name, NULL);
- _exit(255); /* execl() failed */
+ execlp(ctxt->mapname, ctxt->mapname, name, NULL);
+ _exit(255); /* exec() failed */
}
close(pipefd[1]);
close(epipefd[1]);
diff -urpN autofs-4.1.4.a.orig/modules/mount_autofs.c autofs-4.1.4.b.exec/modules/mount_autofs.c
--- autofs-4.1.4.a.orig/modules/mount_autofs.c Mon Jan 10 15:28:29 2005
+++ autofs-4.1.4.b.exec/modules/mount_autofs.c Mon Apr 11 10:20:27 2005
@@ -159,7 +159,7 @@ int mount_mount(const char *root, const
goto error;
} else if (slave == 0) {
/* Slave process */
- execv(PATH_AUTOMOUNT, argv);
+ execvp(PATH_AUTOMOUNT, argv);
_exit(255);
}
diff -urpN autofs-4.1.4.c.messages/daemon/automount.c autofs-4.1.4.d.close/daemon/automount.c
--- autofs-4.1.4.c.messages/daemon/automount.c Mon Apr 11 10:42:39 2005
+++ autofs-4.1.4.d.close/daemon/automount.c Mon Apr 11 10:42:20 2005
@@ -1322,12 +1322,13 @@ static void become_daemon(void)
exit(1);
}
- if (dup2(nullfd, STDIN_FILENO) < 0 ||
- dup2(nullfd, STDOUT_FILENO) < 0 || dup2(nullfd, STDERR_FILENO) < 0) {
+ if (dup2(nullfd, STDIN_FILENO) < 0
+ || dup2(nullfd, STDOUT_FILENO) < 0
+ || dup2(nullfd, STDERR_FILENO) < 0) {
crit("redirecting file descriptors failed: %s", strerror(errno));
exit(1);
}
- close(nullfd);
+ if (nullfd > 2) close(nullfd);
/* Write pid file if requested */
if (pid_file) {
diff -urpN autofs-4.1.4.b.exec/daemon/automount.c autofs-4.1.4.c.messages/daemon/automount.c
--- autofs-4.1.4.b.exec/daemon/automount.c Sun Mar 6 11:43:55 2005
+++ autofs-4.1.4.c.messages/daemon/automount.c Mon Apr 11 10:42:39 2005
@@ -221,7 +221,7 @@ static int rm_unwanted_fn(const char *fi
if (st->st_dev != ap.dev)
return 0;
} else {
- info("rm_unwanted: %s\n", file);
+ info("rm_unwanted: %s", file);
if (S_ISDIR(st->st_mode))
rmdir(file);
else if (!S_ISLNK(st->st_mode) || rmsymlink)
@@ -254,7 +254,7 @@ static int umount_multi(const char *path
struct mnt_list *mntlist = NULL;
struct mnt_list *mptr;
- debug("umount_multi: path=%s incl=%d\n", path, incl);
+ debug("umount_multi: path=%s incl=%d", path, incl);
mntlist = get_mnt_list(_PATH_MOUNTED, path, incl);
@@ -266,7 +266,7 @@ static int umount_multi(const char *path
left = 0;
for (mptr = mntlist; mptr != NULL; mptr = mptr->next) {
- debug("umount_multi: unmounting dir=%s\n", mptr->path);
+ debug("umount_multi: unmounting dir=%s", mptr->path);
if (umount_ent("", mptr->path, mptr->fs_type)) {
left++;
}
@@ -317,7 +317,7 @@ static int do_umount_autofs(void)
PATH_UMOUNT, PATH_UMOUNT, ap.path, NULL);
if (rv & MTAB_NOTUPDATED) {
info("umount %s succeeded: "
- "mtab not updated, retrying to clean\n",
+ "mtab not updated, retrying to clean",
ap.path);
rv = spawnll(LOG_DEBUG,
PATH_UMOUNT, PATH_UMOUNT, ap.path, NULL);
@@ -329,16 +329,16 @@ static int do_umount_autofs(void)
break;
}
if (i < retries - 1) {
- info("umount %s failed: retrying...\n", ap.path);
+ info("umount %s failed: retry
Active Block I/O Scheduling System (ABISS), version 8
The Active Block I/O Scheduling System (ABISS) is an extension of the
hard-disk storage subsystem of Linux, whose main purpose is to provide
a guaranteed reading and (eventually) writing bit rate to applications.
ABISS is conducted by Philips Research in Eindhoven, the Netherlands
(see http://www.research.philips.com/technologies/storage/index.html).
http://abiss.sourceforge.net/abiss-8.tar.gz
md5sum 74199f051c4ef31e38561c695c549813
sha1sum 0f5f04593eb998a41e5184ede503dfffee8d8a9d
This is an important maintenance release, which fixes a bug that could
cause file system corruption. The highlights:
- if ABISS couldn't keep up while writing, pages could be marked for
delayed allocation while locked, badly confusing the rest of the
kernel
- rdrt ("ReaD Real-Time") is now called rwrt ("Read/Write Real-Time")
- rwrt can now invoked without the read/write size argument, which is
convenient if we just want to verify sequence numbers
- communication with abissd used to fail if the file being opened was
badly fragmented (such that the list of fragments was too large to
send). Now, the message size is adjusted dynamically, allowing for
much larger messages.
- added an experimental mechanism for making FAT make contiguous
allocations larger than one cluster. This is activated with the
mount option space=N where N is the number of kilobytes we want
to allocate contiguously. (E.g. if writing two 1MB files in
parallel on a file system with a cluster size of 4 kB, you'd get
about 256 fragments in each. With space=64, there would be only
16 fragments.)
For additional information, please have a look at
http://abiss.sourceforge.net/
- Werner
--
_
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] autofs4 - expiring filesystem from under process
[EMAIL PROTECTED] wrote:
>
> static inline int autofs4_ispending(struct dentry *dentry)
>{
> struct autofs_info *inf = autofs4_dentry_ino(dentry);
> +int pending;
>
> -return (dentry->d_flags & DCACHE_AUTOFS_PENDING) ||
> -(inf != NULL && inf->flags & AUTOFS_INF_EXPIRING);
> +if (dentry->d_flags & DCACHE_AUTOFS_PENDING)
> +return 1;
> +
> +if (inf) {
> +spin_lock(&inf->sbi->fs_lock);
> +pending = inf->flags & AUTOFS_INF_EXPIRING;
> +spin_unlock(&inf->sbi->fs_lock);
> +}
> +
> +return pending;
This can obviously return an uninitialised variable.
Were these patches very well tested?
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
