Re: [mount.c]: Option user-patch
On Wed, 1 Sep 1999 [EMAIL PROTECTED] wrote: On Tue, Aug 31, 1999, Doug Rabson wrote: On Mon, 30 Aug 1999, Andrew J. Korty wrote: I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. Well, sysctl with list of pathes for user mounts looks good. Configuration is simple and can be easliy changed at runtime. It is always better to avoid setuid'ed binaries, this is more worse that mount(8) can execute other mount_* binaries. However, as pointed by Mike Smith, enabling user mounts raises a risc of kernel panics from, for example, corrupted floppy disk. This should lead to more stronger *fs code. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Thu, Sep 02, 1999, Boris Popov wrote: without needing yet another setuid binary/binaries.. Well, sysctl with list of pathes for user mounts looks good. Configuration is simple and can be easliy changed at runtime. It is always better to avoid setuid'ed binaries, this is more worse that mount(8) can execute other mount_* binaries. However, as pointed by Mike Smith, enabling user mounts raises a risc of kernel panics from, for example, corrupted floppy disk. This should lead to more stronger *fs code. Ahh, another discussion entirely, which I'm not going to get into without working code. :-) Adrian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Wed, 1 Sep 1999 [EMAIL PROTECTED] wrote: On Tue, Aug 31, 1999, Doug Rabson wrote: On Mon, 30 Aug 1999, Andrew J. Korty wrote: I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. Well, sysctl with list of pathes for user mounts looks good. Configuration is simple and can be easliy changed at runtime. It is always better to avoid setuid'ed binaries, this is more worse that mount(8) can execute other mount_* binaries. My code provides needed features that all implementations I've seen of the sysctl approach do not. Our users need to mount removable volumes just by clicking on a KDE icon, without having to know what type of filesystem is present on the media. Non-console users should not be permitted to mount removable volumes. Both of these features are provided by my patch, which I have had in production since I submitted it. The possibility of executing undesired mount_* binaries is precluded by the ability to list in the configuration file what filesystem types should be tried for each device. Andrew J. Korty, Director http://www.physics.purdue.edu/~ajk/ Physics Computer Network85 73 1F 04 63 D9 9D 65 Purdue University 65 2E 7A A8 81 8C 45 75 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Thu, Sep 02, 1999, Andrew J. Korty wrote: You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. Well, sysctl with list of pathes for user mounts looks good. Configuration is simple and can be easliy changed at runtime. It is always better to avoid setuid'ed binaries, this is more worse that mount(8) can execute other mount_* binaries. My code provides needed features that all implementations I've seen of the sysctl approach do not. Our users need to mount removable volumes just by clicking on a KDE icon, without having to know what type of filesystem is present on the media. Non-console users should not be permitted to mount removable volumes. Both of these features are provided by my patch, which I have had in production since I submitted it. There are saner ways than using a suid binary. Countering your arguement.. sysctl -w vfs.usermount="/floppy:/cdrom" And they can mount/umount at whim if they own the mountpoint/have done the mount (and the permission checking can be extended to suit..) Then all you need to do is think of a sane way to chown console devices (floppy, cdrom, etc..) to the user when they login? Perhaps an extension to login/xdm/whatever kde uses ? All I'm saying is there has to be a better way to solve a problem using an iron pole, regardless of whether its first stuck inside a nerf dart. Adrian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Fri, 3 Sep 1999 [EMAIL PROTECTED] wrote: :Then all you need to do is think of a sane way to chown console devices :(floppy, cdrom, etc..) to the user when they login? Perhaps an extension :to login/xdm/whatever kde uses ? You can do this in /etc/fbtab. You already chown the console for X logging (you should be anyway). I don't like the idea of restricting access to the console user. That assumes that the removable media device in question is present on every machine in the room. This is not always the case. It may not even be the dominant case. Jamie Bowden -- If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Thu, Sep 02, 1999, Andrew J. Korty wrote: You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. Well, sysctl with list of pathes for user mounts looks good. Configuration is simple and can be easliy changed at runtime. It is always better to avoid setuid'ed binaries, this is more worse that mount(8) can execute other mount_* binaries. My code provides needed features that all implementations I've seen of the sysctl approach do not. Our users need to mount removable volumes just by clicking on a KDE icon, without having to know what type of filesystem is present on the media. Non-console users should not be permitted to mount removable volumes. Both of these features are provided by my patch, which I have had in production since I submitted it. There are saner ways than using a suid binary. Countering your arguement.. sysctl -w vfs.usermount="/floppy:/cdrom" And they can mount/umount at whim if they own the mountpoint/have done the mount (and the permission checking can be extended to suit..) Then all you need to do is think of a sane way to chown console devices (floppy, cdrom, etc..) to the user when they login? Perhaps an extension to login/xdm/whatever kde uses ? The user would still have to know what type of filesystem is on the volume. My code tries filesystem types from a list, one by one, so the same command or desktop icon will mount a FAT, UFS, or EXT2FS floppy, for example. The system administrator can also specify default mount options on a device or filesystem-type basis. ajk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
The user would still have to know what type of filesystem is on the volume. My code tries filesystem types from a list, one by one, so the same command or desktop icon will mount a FAT, UFS, or EXT2FS floppy, for example. The system administrator can also specify default mount options on a device or filesystem-type basis. I like that idea, but that still doesn't need suid privs to do. Adrian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Fri, Sep 03, 1999 at 03:01:26AM +0800, [EMAIL PROTECTED] wrote: The user would still have to know what type of filesystem is on the volume. My code tries filesystem types from a list, one by one, so the same command or desktop icon will mount a FAT, UFS, or EXT2FS floppy, for example. The system administrator can also specify default mount options on a device or filesystem-type basis. I like that idea, but that still doesn't need suid privs to do. But the mount call does. I agree that you need to specify the mount restrictions centrally. Otherwise what's to prevent me (the user) from making a floppy with a suid shell, and mounting it? It makes sense in some situations for only the user on the console to be able to perform mount operations, and to own the files once they get mounted. This is essential for a lab environment. If the options aren't appropriate for you, then configure things differently. Real configuration files are needed for this functionality. I don't buy that getting the config into/out-of the kernel is easier/better than a carefully crafted suid binary. If someone wants to propose an alternate mount API into the kernel that would provide for this functionality... that might be the best of both worlds... I've not looked at the problem in much detail though, but it would seem to address some concerns and keep the features that Mr. Korty has implemented and contributed. This still doesn't entirely - Steve -- WaterSpout Communications, Inc.[EMAIL PROTECTED] 427 North 6th Street http://www.waterspout.com/ Lafayette, IN 47901 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
This still doesn't entirely Oops. I didn't finish that thought again after the vi -r. I meant to say that even with a modifed kernel mount() call, there are difficulties getting all of the configuration possibities into the kernel propper. (Mount Options, What FS types to try, etc). - Steve -- WaterSpout Communications, Inc.[EMAIL PROTECTED] 427 North 6th Street http://www.waterspout.com/ Lafayette, IN 47901 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Wed, 1 Sep 1999 adr...@freebsd.org wrote: On Tue, Aug 31, 1999, Doug Rabson wrote: On Mon, 30 Aug 1999, Andrew J. Korty wrote: I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. Well, sysctl with list of pathes for user mounts looks good. Configuration is simple and can be easliy changed at runtime. It is always better to avoid setuid'ed binaries, this is more worse that mount(8) can execute other mount_* binaries. However, as pointed by Mike Smith, enabling user mounts raises a risc of kernel panics from, for example, corrupted floppy disk. This should lead to more stronger *fs code. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Thu, Sep 02, 1999, Boris Popov wrote: without needing yet another setuid binary/binaries.. Well, sysctl with list of pathes for user mounts looks good. Configuration is simple and can be easliy changed at runtime. It is always better to avoid setuid'ed binaries, this is more worse that mount(8) can execute other mount_* binaries. However, as pointed by Mike Smith, enabling user mounts raises a risc of kernel panics from, for example, corrupted floppy disk. This should lead to more stronger *fs code. Ahh, another discussion entirely, which I'm not going to get into without working code. :-) Adrian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Wed, 1 Sep 1999 adr...@freebsd.org wrote: On Tue, Aug 31, 1999, Doug Rabson wrote: On Mon, 30 Aug 1999, Andrew J. Korty wrote: I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. Well, sysctl with list of pathes for user mounts looks good. Configuration is simple and can be easliy changed at runtime. It is always better to avoid setuid'ed binaries, this is more worse that mount(8) can execute other mount_* binaries. My code provides needed features that all implementations I've seen of the sysctl approach do not. Our users need to mount removable volumes just by clicking on a KDE icon, without having to know what type of filesystem is present on the media. Non-console users should not be permitted to mount removable volumes. Both of these features are provided by my patch, which I have had in production since I submitted it. The possibility of executing undesired mount_* binaries is precluded by the ability to list in the configuration file what filesystem types should be tried for each device. Andrew J. Korty, Director http://www.physics.purdue.edu/~ajk/ Physics Computer Network85 73 1F 04 63 D9 9D 65 Purdue University 65 2E 7A A8 81 8C 45 75 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Thu, Sep 02, 1999, Andrew J. Korty wrote: You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. Well, sysctl with list of pathes for user mounts looks good. Configuration is simple and can be easliy changed at runtime. It is always better to avoid setuid'ed binaries, this is more worse that mount(8) can execute other mount_* binaries. My code provides needed features that all implementations I've seen of the sysctl approach do not. Our users need to mount removable volumes just by clicking on a KDE icon, without having to know what type of filesystem is present on the media. Non-console users should not be permitted to mount removable volumes. Both of these features are provided by my patch, which I have had in production since I submitted it. There are saner ways than using a suid binary. Countering your arguement.. sysctl -w vfs.usermount=/floppy:/cdrom And they can mount/umount at whim if they own the mountpoint/have done the mount (and the permission checking can be extended to suit..) Then all you need to do is think of a sane way to chown console devices (floppy, cdrom, etc..) to the user when they login? Perhaps an extension to login/xdm/whatever kde uses ? All I'm saying is there has to be a better way to solve a problem using an iron pole, regardless of whether its first stuck inside a nerf dart. Adrian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Fri, 3 Sep 1999 adr...@freebsd.org wrote: :Then all you need to do is think of a sane way to chown console devices :(floppy, cdrom, etc..) to the user when they login? Perhaps an extension :to login/xdm/whatever kde uses ? You can do this in /etc/fbtab. You already chown the console for X logging (you should be anyway). I don't like the idea of restricting access to the console user. That assumes that the removable media device in question is present on every machine in the room. This is not always the case. It may not even be the dominant case. Jamie Bowden -- If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Thu, Sep 02, 1999, Andrew J. Korty wrote: You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. Well, sysctl with list of pathes for user mounts looks good. Configuration is simple and can be easliy changed at runtime. It is always better to avoid setuid'ed binaries, this is more worse that mount(8) can execute other mount_* binaries. My code provides needed features that all implementations I've seen of the sysctl approach do not. Our users need to mount removable volumes just by clicking on a KDE icon, without having to know what type of filesystem is present on the media. Non-console users should not be permitted to mount removable volumes. Both of these features are provided by my patch, which I have had in production since I submitted it. There are saner ways than using a suid binary. Countering your arguement.. sysctl -w vfs.usermount=/floppy:/cdrom And they can mount/umount at whim if they own the mountpoint/have done the mount (and the permission checking can be extended to suit..) Then all you need to do is think of a sane way to chown console devices (floppy, cdrom, etc..) to the user when they login? Perhaps an extension to login/xdm/whatever kde uses ? The user would still have to know what type of filesystem is on the volume. My code tries filesystem types from a list, one by one, so the same command or desktop icon will mount a FAT, UFS, or EXT2FS floppy, for example. The system administrator can also specify default mount options on a device or filesystem-type basis. ajk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
The user would still have to know what type of filesystem is on the volume. My code tries filesystem types from a list, one by one, so the same command or desktop icon will mount a FAT, UFS, or EXT2FS floppy, for example. The system administrator can also specify default mount options on a device or filesystem-type basis. I like that idea, but that still doesn't need suid privs to do. Adrian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Fri, Sep 03, 1999 at 03:01:26AM +0800, adr...@freebsd.org wrote: The user would still have to know what type of filesystem is on the volume. My code tries filesystem types from a list, one by one, so the same command or desktop icon will mount a FAT, UFS, or EXT2FS floppy, for example. The system administrator can also specify default mount options on a device or filesystem-type basis. I like that idea, but that still doesn't need suid privs to do. But the mount call does. I agree that you need to specify the mount restrictions centrally. Otherwise what's to prevent me (the user) from making a floppy with a suid shell, and mounting it? It makes sense in some situations for only the user on the console to be able to perform mount operations, and to own the files once they get mounted. This is essential for a lab environment. If the options aren't appropriate for you, then configure things differently. Real configuration files are needed for this functionality. I don't buy that getting the config into/out-of the kernel is easier/better than a carefully crafted suid binary. If someone wants to propose an alternate mount API into the kernel that would provide for this functionality... that might be the best of both worlds... I've not looked at the problem in much detail though, but it would seem to address some concerns and keep the features that Mr. Korty has implemented and contributed. This still doesn't entirely - Steve -- WaterSpout Communications, Inc.c...@waterspout.com 427 North 6th Street http://www.waterspout.com/ Lafayette, IN 47901 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
This still doesn't entirely Oops. I didn't finish that thought again after the vi -r. I meant to say that even with a modifed kernel mount() call, there are difficulties getting all of the configuration possibities into the kernel propper. (Mount Options, What FS types to try, etc). - Steve -- WaterSpout Communications, Inc.c...@waterspout.com 427 North 6th Street http://www.waterspout.com/ Lafayette, IN 47901 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Mon, 30 Aug 1999, Andrew J. Korty wrote: I suppose there already was a rather lengthy discussion about a "user"-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * [EMAIL PROTECTED] * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Tue, Aug 31, 1999, Doug Rabson wrote: On Mon, 30 Aug 1999, Andrew J. Korty wrote: I suppose there already was a rather lengthy discussion about a "user"-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * [EMAIL PROTECTED] * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. http://www.freebsd.org/~adrian/usermount/ Read the README, I wrote this in a hurry, and its more a proof of concept things more than anything else.. Comments welcome. Adrian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Mon, 30 Aug 1999, Andrew J. Korty wrote: I suppose there already was a rather lengthy discussion about a user-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * st...@pool.informatik.rwth-aachen.de * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Tue, Aug 31, 1999, Doug Rabson wrote: On Mon, 30 Aug 1999, Andrew J. Korty wrote: I suppose there already was a rather lengthy discussion about a user-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * st...@pool.informatik.rwth-aachen.de * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. http://www.freebsd.org/~adrian/usermount/ Read the README, I wrote this in a hurry, and its more a proof of concept things more than anything else.. Comments welcome. Adrian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
so where re you at the moment? julian On Wed, 1 Sep 1999 adr...@freebsd.org wrote: Comments welcome. Adrian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
I suppose there already was a rather lengthy discussion about a "user"-option. I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * [EMAIL PROTECTED] * PGP To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
I suppose there already was a rather lengthy discussion about a "user"-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * [EMAIL PROTECTED] * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. Andrew J. Korty, Director http://www.physics.purdue.edu/~ajk/ Physics Computer Network85 73 1F 04 63 D9 9D 65 Purdue University 65 2E 7A A8 81 8C 45 75 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
I suppose there already was a rather lengthy discussion about a user-option. I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * st...@pool.informatik.rwth-aachen.de * PGP To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
I suppose there already was a rather lengthy discussion about a user-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * st...@pool.informatik.rwth-aachen.de * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. Andrew J. Korty, Director http://www.physics.purdue.edu/~ajk/ Physics Computer Network85 73 1F 04 63 D9 9D 65 Purdue University 65 2E 7A A8 81 8C 45 75 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
vs I whacked mount and umount into shape for using an option "user" in [snip] vs http://www-i2.informatik.rwth-aachen.de/~stolz/mount.diff vs http://www-i2.informatik.rwth-aachen.de/~stolz/umount.diff. vs Discussion welcome! You can allow non-root users to mount and unmount devices if the sysctl variable "vfs.usermount" is set to "1". For example, here's what you need to do to allow floppies to be mounted: As `root': 1. # chmod 777 /dev/fd0 # give perms to access the device 2. # sysctl -w vfs.usermount=1 Now users can mount and umount the floppies: 3. $ mkdir ~/my-mount-point 4. $ mount -t msdos /dev/fd0 ~/my-mount-point 5. $ umount ~/my-mount-point A FAQ entry covering this point is being reviewed and should shortly be committed. Regards, Koshy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Sun, 29 Aug 1999, Natty Rebel wrote:
Quoting JK3 ([EMAIL PROTECTED]):
vs I whacked mount and umount into shape for using an option "user" in
[snip]
vs http://www-i2.informatik.rwth-aachen.de/~stolz/mount.diff
vs http://www-i2.informatik.rwth-aachen.de/~stolz/umount.diff.
vs Discussion welcome!
You can allow non-root users to mount and unmount devices if
the sysctl variable "vfs.usermount" is set to "1".
For example, here's what you need to do to allow floppies to
be mounted:
As `root':
1. # chmod 777 /dev/fd0 # give perms to access the device
2. # sysctl -w vfs.usermount=1
Now users can mount and umount the floppies:
3. $ mkdir ~/my-mount-point
4. $ mount -t msdos /dev/fd0 ~/my-mount-point
5. $ umount ~/my-mount-point
A FAQ entry covering this point is being reviewed and should shortly
be committed.
This procedure can be automated by entering the following command
in /etc/rc.sysctl
sysctl -w vfs.usermount=1
Maybe it's just me, but I think you are confusing this with
{Net|Open}BSD. /etc/rc.sysctl does not exist in FreeBSD.
-
Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never
System/Network Administrator,| claimed they were one, and always
Reality Check Information, Inc. | pointed to someone better.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Sun, 29 Aug 1999, Chris Piazza wrote:
On Sun, Aug 29, 1999 at 06:30:35PM -0400, Chris D. Faulhaber wrote:
On Sun, 29 Aug 1999, Natty Rebel wrote:
This procedure can be automated by entering the following command
in /etc/rc.sysctl
sysctl -w vfs.usermount=1
Maybe it's just me, but I think you are confusing this with
{Net|Open}BSD. /etc/rc.sysctl does not exist in FreeBSD.
From /etc/rc:
# set sysctl variables early as we can
if [ -f /etc/rc.sysctl ]; then
. /etc/rc.sysctl
fi
Mind you it doesn't look like it was merged into releng_3
Yep, not in -stable ...
... wow, guess I've been blindly going through mergemaster lately with
-current...
-
Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never
System/Network Administrator,| claimed they were one, and always
Reality Check Information, Inc. | pointed to someone better.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Sun, 29 Aug 1999, Chris Piazza wrote: # set sysctl variables early as we can if [ -f /etc/rc.sysctl ]; then . /etc/rc.sysctl fi Mind you it doesn't look like it was merged into releng_3 Could someone do this before 3.3? It's useful functionality. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Mon, 30 Aug 1999, Alban Hertroys wrote:
I have seen this line a lot lately. It isn't in FreeBSD 3.2-STABLE, is
it? My /usr/src/sbin/mount/mount.c says:
/*
* If the mount was successfully, and done by root, tell mountd the
* good news. Pid checks are probably unnecessary, but don't hurt.
*/
if (rval == 0 getuid() == 0
(mountdfp = fopen(_PATH_MOUNTDPID, "r")) != NULL) {
if (fscanf(mountdfp, "%d", pid) == 1
pid 0 kill(pid, SIGHUP) == -1 errno != ESRCH)
err(1, "signal mountd");
(void)fclose(mountdfp);
}
getuid() == 0 looks a lot like root-only to me... Or am I missing
something?
You are. This code says "if we're root, give mountd(8) a SIGHUP".
According to the mountd(8) manpage, "After changing the exports file, a
hangup signal should be sent to the mountd daemon to get it to reload the
export information."
==
If there is a here-after,
then there are much more people dead than alive.
I dispute this :-) The population of the world has been growing
exponentially for some centuries at least. One property of exponential
curves (f(x) = a^x) is that the area beneath the curve up to any given
point is equal to the value of the function at that point (up to a
constant scaling factor ln a).
Thus, the number of people currently alive is approximately equal to those
who have ever lived (and died).
Kris
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
Quoting Chris D. Faulhaber ([EMAIL PROTECTED]):
On Sun, 29 Aug 1999, Chris Piazza wrote:
On Sun, Aug 29, 1999 at 06:30:35PM -0400, Chris D. Faulhaber wrote:
On Sun, 29 Aug 1999, Natty Rebel wrote:
This procedure can be automated by entering the following command
in /etc/rc.sysctl
sysctl -w vfs.usermount=1
Maybe it's just me, but I think you are confusing this with
{Net|Open}BSD. /etc/rc.sysctl does not exist in FreeBSD.
From /etc/rc:
# set sysctl variables early as we can
if [ -f /etc/rc.sysctl ]; then
. /etc/rc.sysctl
fi
Mind you it doesn't look like it was merged into releng_3
Yep, not in -stable ...
... wow, guess I've been blindly going through mergemaster lately with
-current...
Yeah, I just caught this myself after my -current build yesterday ...
-
Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never
System/Network Administrator,| claimed they were one, and always
Reality Check Information, Inc. | pointed to someone better.
#:^)
--
natty rebel
harder than the rest ...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
In message [EMAIL PROTECTED] Kris Kennaway writes: : Could someone do this before 3.3? It's useful functionality. As the committer of this feature, I've just sent mail to jkh asking for permission. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
vs I whacked mount and umount into shape for using an option "user" in [snip] vs http://www-i2.informatik.rwth-aachen.de/~stolz/mount.diff vs http://www-i2.informatik.rwth-aachen.de/~stolz/umount.diff. You can allow non-root users to mount and unmount devices if the sysctl variable "vfs.usermount" is set to "1". The Linux 'user' option has the distinct advantage that it allows the administrator to specify which filesystems can be mounted by users. IIRC, Linux also permits the administrator to discriminate two variants: One in which an arbitrary user may mount and an (independently) arbitrary user may subsequently unmount, and a second in which an arbitrary user may mount, and only that same user (or root) may subsequently unmount, a specific given filesystem. It's good to have this kind of control. vfs.usermount does not directly support this control. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Sun, 29 Aug 1999, Warner Losh wrote:
In message [EMAIL PROTECTED] "Chris
D. Faulhaber" writes:
: Maybe it's just me, but I think you are confusing this with
: {Net|Open}BSD. /etc/rc.sysctl does not exist in FreeBSD.
rc.sysctl does too. I added it.
Excellent. That will be a nice feature to have in 3.x.
-
Chris D. Faulhaber [EMAIL PROTECTED] | All the true gurus I've met never
System/Network Administrator,| claimed they were one, and always
Reality Check Information, Inc. | pointed to someone better.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Sun, Aug 29, 1999 at 10:47:05PM -0600, Warner Losh wrote: As the committer of this feature, I've just sent mail to jkh asking for permission. How does this change relate to bin/11031? The above patches weren't written by me, but by a co-worker of mine. It allows for a termcap-like configuration file /etc/mountcap that allows you to specify a mountpoint/device, options, and filesystem formats to try. But best of all it allows you to check the ownership of a file or device to see if the user is logged in on console. For workstations that need user mounts you really don't want non-console users to futz with the removable media devices. Just wanted to remind ya all it was there. - Steve -- WaterSpout Communications, Inc.[EMAIL PROTECTED] 427 North 6th Street http://www.waterspout.com/ Lafayette, IN 47901 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
vs I whacked mount and umount into shape for using an option user in [snip] vs http://www-i2.informatik.rwth-aachen.de/~stolz/mount.diff vs http://www-i2.informatik.rwth-aachen.de/~stolz/umount.diff. vs Discussion welcome! You can allow non-root users to mount and unmount devices if the sysctl variable vfs.usermount is set to 1. For example, here's what you need to do to allow floppies to be mounted: As `root': 1. # chmod 777 /dev/fd0 # give perms to access the device 2. # sysctl -w vfs.usermount=1 Now users can mount and umount the floppies: 3. $ mkdir ~/my-mount-point 4. $ mount -t msdos /dev/fd0 ~/my-mount-point 5. $ umount ~/my-mount-point A FAQ entry covering this point is being reviewed and should shortly be committed. Regards, Koshy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
Quoting JK3 (j...@bgl.vsnl.net.in): vs I whacked mount and umount into shape for using an option user in [snip] vs http://www-i2.informatik.rwth-aachen.de/~stolz/mount.diff vs http://www-i2.informatik.rwth-aachen.de/~stolz/umount.diff. vs Discussion welcome! You can allow non-root users to mount and unmount devices if the sysctl variable vfs.usermount is set to 1. For example, here's what you need to do to allow floppies to be mounted: As `root': 1. # chmod 777 /dev/fd0 # give perms to access the device 2. # sysctl -w vfs.usermount=1 Now users can mount and umount the floppies: 3. $ mkdir ~/my-mount-point 4. $ mount -t msdos /dev/fd0 ~/my-mount-point 5. $ umount ~/my-mount-point A FAQ entry covering this point is being reviewed and should shortly be committed. This procedure can be automated by entering the following command in /etc/rc.sysctl sysctl -w vfs.usermount=1 Regards, Koshy #:^) -- natty rebel harder than the rest ... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Sun, 29 Aug 1999, Natty Rebel wrote:
Quoting JK3 (j...@bgl.vsnl.net.in):
vs I whacked mount and umount into shape for using an option user in
[snip]
vs http://www-i2.informatik.rwth-aachen.de/~stolz/mount.diff
vs http://www-i2.informatik.rwth-aachen.de/~stolz/umount.diff.
vs Discussion welcome!
You can allow non-root users to mount and unmount devices if
the sysctl variable vfs.usermount is set to 1.
For example, here's what you need to do to allow floppies to
be mounted:
As `root':
1. # chmod 777 /dev/fd0 # give perms to access the device
2. # sysctl -w vfs.usermount=1
Now users can mount and umount the floppies:
3. $ mkdir ~/my-mount-point
4. $ mount -t msdos /dev/fd0 ~/my-mount-point
5. $ umount ~/my-mount-point
A FAQ entry covering this point is being reviewed and should shortly
be committed.
This procedure can be automated by entering the following command
in /etc/rc.sysctl
sysctl -w vfs.usermount=1
Maybe it's just me, but I think you are confusing this with
{Net|Open}BSD. /etc/rc.sysctl does not exist in FreeBSD.
-
Chris D. Faulhaber jed...@fxp.org | All the true gurus I've met never
System/Network Administrator,| claimed they were one, and always
Reality Check Information, Inc. | pointed to someone better.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Sun, Aug 29, 1999 at 06:30:35PM -0400, Chris D. Faulhaber wrote:
On Sun, 29 Aug 1999, Natty Rebel wrote:
This procedure can be automated by entering the following command
in /etc/rc.sysctl
sysctl -w vfs.usermount=1
Maybe it's just me, but I think you are confusing this with
{Net|Open}BSD. /etc/rc.sysctl does not exist in FreeBSD.
Re: [mount.c]: Option user-patch
On 29 Aug, Chris Piazza wrote:
On Sun, Aug 29, 1999 at 06:30:35PM -0400, Chris D. Faulhaber wrote:
On Sun, 29 Aug 1999, Natty Rebel wrote:
This procedure can be automated by entering the following command
in /etc/rc.sysctl
sysctl -w vfs.usermount=1
I have seen this line a lot lately. It isn't in FreeBSD 3.2-STABLE, is
it? My /usr/src/sbin/mount/mount.c says:
/*
* If the mount was successfully, and done by root, tell mountd the
* good news. Pid checks are probably unnecessary, but don't hurt.
*/
if (rval == 0 getuid() == 0
(mountdfp = fopen(_PATH_MOUNTDPID, r)) != NULL) {
if (fscanf(mountdfp, %d, pid) == 1
pid 0 kill(pid, SIGHUP) == -1 errno != ESRCH)
err(1, signal mountd);
(void)fclose(mountdfp);
}
getuid() == 0 looks a lot like root-only to me... Or am I missing
something?
--
Alban Hertroys.
http://wit401310.student.utwente.nl
==
If there is a here-after,
then there are much more people dead than alive.
Even that much more that the number of living people
is insignificant in comparison to the dead ones.
Thus it is safe to say that we don't exist.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Sun, 29 Aug 1999, Chris Piazza wrote:
On Sun, Aug 29, 1999 at 06:30:35PM -0400, Chris D. Faulhaber wrote:
On Sun, 29 Aug 1999, Natty Rebel wrote:
This procedure can be automated by entering the following command
in /etc/rc.sysctl
sysctl -w vfs.usermount=1
Maybe it's just me, but I think you are confusing this with
{Net|Open}BSD. /etc/rc.sysctl does not exist in FreeBSD.
From /etc/rc:
# set sysctl variables early as we can
if [ -f /etc/rc.sysctl ]; then
. /etc/rc.sysctl
fi
Mind you it doesn't look like it was merged into releng_3
Yep, not in -stable ...
... wow, guess I've been blindly going through mergemaster lately with
-current...
-
Chris D. Faulhaber jed...@fxp.org | All the true gurus I've met never
System/Network Administrator,| claimed they were one, and always
Reality Check Information, Inc. | pointed to someone better.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Sun, 29 Aug 1999, Chris Piazza wrote: # set sysctl variables early as we can if [ -f /etc/rc.sysctl ]; then . /etc/rc.sysctl fi Mind you it doesn't look like it was merged into releng_3 Could someone do this before 3.3? It's useful functionality. Kris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Mon, 30 Aug 1999, Alban Hertroys wrote:
I have seen this line a lot lately. It isn't in FreeBSD 3.2-STABLE, is
it? My /usr/src/sbin/mount/mount.c says:
/*
* If the mount was successfully, and done by root, tell mountd the
* good news. Pid checks are probably unnecessary, but don't hurt.
*/
if (rval == 0 getuid() == 0
(mountdfp = fopen(_PATH_MOUNTDPID, r)) != NULL) {
if (fscanf(mountdfp, %d, pid) == 1
pid 0 kill(pid, SIGHUP) == -1 errno != ESRCH)
err(1, signal mountd);
(void)fclose(mountdfp);
}
getuid() == 0 looks a lot like root-only to me... Or am I missing
something?
You are. This code says if we're root, give mountd(8) a SIGHUP.
According to the mountd(8) manpage, After changing the exports file, a
hangup signal should be sent to the mountd daemon to get it to reload the
export information.
==
If there is a here-after,
then there are much more people dead than alive.
I dispute this :-) The population of the world has been growing
exponentially for some centuries at least. One property of exponential
curves (f(x) = a^x) is that the area beneath the curve up to any given
point is equal to the value of the function at that point (up to a
constant scaling factor ln a).
Thus, the number of people currently alive is approximately equal to those
who have ever lived (and died).
Kris
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
Quoting Chris D. Faulhaber (jed...@fxp.org):
On Sun, 29 Aug 1999, Chris Piazza wrote:
On Sun, Aug 29, 1999 at 06:30:35PM -0400, Chris D. Faulhaber wrote:
On Sun, 29 Aug 1999, Natty Rebel wrote:
This procedure can be automated by entering the following command
in /etc/rc.sysctl
sysctl -w vfs.usermount=1
Maybe it's just me, but I think you are confusing this with
{Net|Open}BSD. /etc/rc.sysctl does not exist in FreeBSD.
From /etc/rc:
# set sysctl variables early as we can
if [ -f /etc/rc.sysctl ]; then
. /etc/rc.sysctl
fi
Mind you it doesn't look like it was merged into releng_3
Yep, not in -stable ...
... wow, guess I've been blindly going through mergemaster lately with
-current...
Yeah, I just caught this myself after my -current build yesterday ...
-
Chris D. Faulhaber jed...@fxp.org | All the true gurus I've met never
System/Network Administrator,| claimed they were one, and always
Reality Check Information, Inc. | pointed to someone better.
#:^)
--
natty rebel
harder than the rest ...
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
In message pine.bsf.4.10.9908291829260.61952-100...@pawn.primelocation.net
Chris D. Faulhaber writes:
: Maybe it's just me, but I think you are confusing this with
: {Net|Open}BSD. /etc/rc.sysctl does not exist in FreeBSD.
rc.sysctl does too. I added it.
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
In message pine.bsf.4.10.9908291552200.47871-100...@hub.freebsd.org Kris Kennaway writes: : Could someone do this before 3.3? It's useful functionality. As the committer of this feature, I've just sent mail to jkh asking for permission. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
vs I whacked mount and umount into shape for using an option user in [snip] vs http://www-i2.informatik.rwth-aachen.de/~stolz/mount.diff vs http://www-i2.informatik.rwth-aachen.de/~stolz/umount.diff. You can allow non-root users to mount and unmount devices if the sysctl variable vfs.usermount is set to 1. The Linux 'user' option has the distinct advantage that it allows the administrator to specify which filesystems can be mounted by users. IIRC, Linux also permits the administrator to discriminate two variants: One in which an arbitrary user may mount and an (independently) arbitrary user may subsequently unmount, and a second in which an arbitrary user may mount, and only that same user (or root) may subsequently unmount, a specific given filesystem. It's good to have this kind of control. vfs.usermount does not directly support this control. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Sun, 29 Aug 1999, Warner Losh wrote:
In message pine.bsf.4.10.9908291829260.61952-100...@pawn.primelocation.net
Chris D. Faulhaber writes:
: Maybe it's just me, but I think you are confusing this with
: {Net|Open}BSD. /etc/rc.sysctl does not exist in FreeBSD.
rc.sysctl does too. I added it.
Excellent. That will be a nice feature to have in 3.x.
-
Chris D. Faulhaber jed...@fxp.org | All the true gurus I've met never
System/Network Administrator,| claimed they were one, and always
Reality Check Information, Inc. | pointed to someone better.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Sun, Aug 29, 1999 at 10:47:05PM -0600, Warner Losh wrote: As the committer of this feature, I've just sent mail to jkh asking for permission. How does this change relate to bin/11031? The above patches weren't written by me, but by a co-worker of mine. It allows for a termcap-like configuration file /etc/mountcap that allows you to specify a mountpoint/device, options, and filesystem formats to try. But best of all it allows you to check the ownership of a file or device to see if the user is logged in on console. For workstations that need user mounts you really don't want non-console users to futz with the removable media devices. Just wanted to remind ya all it was there. - Steve -- WaterSpout Communications, Inc.c...@waterspout.com 427 North 6th Street http://www.waterspout.com/ Lafayette, IN 47901 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
In message 1999083324.a29...@tsunami.waterspout.com C. Stephen Gunn writes: : The above patches weren't written by me, but by a co-worker of : mine. It allows for a termcap-like configuration file /etc/mountcap : that allows you to specify a mountpoint/device, options, and filesystem : formats to try. Doesn't. I'm just wanting to merge /etc/rc.sysctl back. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
