On 08.04.2006, at 5:04, Jeremy Baggs wrote:
I suppose it would be nice to have something that works "out of the
box", but the solution I have been using
is group permissions on the devices and then making the mount point
in fstab relative instead of absolute. ie:
/dev/cd0 cdrom
I suppose it would be nice to have something that works "out of the
box", but the solution I have been using
is group permissions on the devices and then making the mount point in
fstab relative instead of absolute. ie:
/dev/cd0 cdrom cd9660 ro,noauto 0 0
Each user ha
Anyway, I consider this to be a "hack" too :-)
> Hello all,
>
> I've been watching this thread with some interest.
>
> I have actually found quite a straightforward solution to this problem that
> works for me under FreeBSD, and requires no extra entries in fstab, scripts
> changing permissions on
Hello all,
I've been watching this thread with some interest.
I have actually found quite a straightforward solution to this problem that
works for me under FreeBSD, and requires no extra entries in fstab, scripts
changing permissions on login, or any other fairly ugly workaround.
I assume tha
On Thu, Apr 06, 2006 at 12:37:03PM -0700, Darren Pilgrim wrote:
> >Access control is done via permissions of files in /dev. If I have
> >proper permissions to a device file, I can mount it at a directory
> >I own. If I don't have proper permissions to a device file, I cannot
> >mount it at all. Thi
In <[EMAIL PROTECTED]>, Jilles Tjoelker <[EMAIL PROTECTED]> typed:
> Consider chown(8)ing the mount points to the current user on login (and
> root on logout) (using DisplayManager._0.startup and
> DisplayManager._0.reset or similar).
/etc/fbtab is designed for exactly this problem. That's what I
On Tue, Apr 04, 2006 at 01:45:47PM +0200, Stefan Sperling wrote:
> Why do GNOME/KDE rely on /etc/fstab on FreeBSD?
> What are admins supposed to do on systems with more than, say, a hundred
> users. Having to add a line to /etc/fstab for every user is of course
> scriptable, but that does not make
On Thu, 6 Apr 2006, Peter Jeremy wrote:
On Wed, 2006-Apr-05 12:14:29 -0500, Rick C. Petty wrote:
If not operator, then maybe one configurable group, defaulting to operator.
Sounds like a good idea.
--
Peter Jeremy
What group do NFS and SMBFS shares belong to?
Mike "Silby" Silbersack
On Wed, 2006-Apr-05 12:14:29 -0500, Rick C. Petty wrote:
>On Tue, Apr 04, 2006 at 10:00:00AM -0500, Sergey Babkin wrote:
>>
>> Would it make sense to be able to specify a group in fstab?
>> Then the users can be simply given membership of this
>> group to mount the devices.
>
>Why not just assume
On Tue, Apr 04, 2006 at 10:00:00AM -0500, Sergey Babkin wrote:
>
> Would it make sense to be able to specify a group in fstab?
> Then the users can be simply given membership of this
> group to mount the devices.
Why not just assume allowable users are in the "operator" group. Isn't
this what th
On Wed, 5 Apr 2006, Stefan Sperling wrote:
I wasn't serious. Sudo is fine by me as well. However, having something that
is in the base system (and not in ports) to allow user mounts would be neat.
Still, KDE and GNOME and even xorg are in ports as well, so that point is
not a really strong on
On Wed, Apr 05, 2006 at 01:37:11PM +0100, Jan Grant wrote:
> On Wed, 5 Apr 2006, Stefan Sperling wrote:
>
> > On Tue, Apr 04, 2006 at 09:52:17PM -0800, [EMAIL PROTECTED] wrote:
> > >
> > > > So why not have GNOME/KDE create mount points for the user if
> > > > vfs.usermount is 1?
> > > pardon my
On Wed, 5 Apr 2006, Stefan Sperling wrote:
> On Tue, Apr 04, 2006 at 09:52:17PM -0800, [EMAIL PROTECTED] wrote:
> >
> > > So why not have GNOME/KDE create mount points for the user if
> > > vfs.usermount is 1?
> > pardon my ignorance, but how any of those methods described earlier may
> > be supe
>From: Stefan Sperling <[EMAIL PROTECTED]>
>What are admins supposed to do on systems with more than, say, a hundred
>users. Having to add a line to /etc/fstab for every user is of course
>scriptable, but that does not make it less insane.
Would it make sense to be able to specify a group in fstab
On Tue, Apr 04, 2006 at 09:52:17PM -0800, [EMAIL PROTECTED] wrote:
>
> > So why not have GNOME/KDE create mount points for the user if
> > vfs.usermount is 1?
> pardon my ignorance, but how any of those methods described earlier may
> be superior to simply using sudo?
Using sudo is a hack? :)
--
> So why not have GNOME/KDE create mount points for the user if
> vfs.usermount is 1? Since FreeBSD uses devfs, every device in /dev that
> usually represents a device with removable media can assumed to be
> present in hardware. GNOME/KDE could be patched to create mount points
> somewhere in the
Stefan Sperling wrote:
Why do GNOME/KDE rely on /etc/fstab on FreeBSD?
GNOME/KDE could be patched to create mount points
somewhere in the user's home directory, and issue a 'mount device mount_point'
instead of 'mount mount_point' if the user clicks the device icon.
Limiting GNOME/KDE to just
On Tue, Apr 04, 2006 at 02:47:18AM -0400, Joe Marcus Clarke wrote:
> On Tue, 2006-04-04 at 08:30 +0200, Alex Dupre wrote:
> > Joe Marcus Clarke wrote:
> > > What I'd like to achieve is a simple out-of-the-box way of mounting
> > > media such as CDs, and floppy disks without users necessarily needin
On Mon, 2006-04-03 at 23:30 +0100, Robert Watson wrote:
> On Mon, 3 Apr 2006, Joe Marcus Clarke wrote:
>
> >> I would suggest that an extremely careful security audit of the userspace
> >> and kernel mount and unmount code is due -- especially things like the
> >> per-filesystem mount code (moun
On Tue, 2006-04-04 at 08:30 +0200, Alex Dupre wrote:
> Joe Marcus Clarke wrote:
> > What I'd like to achieve is a simple out-of-the-box way of mounting
> > media such as CDs, and floppy disks without users necessarily needing to
> > know about sysctl. While I can't speak for KDE, I know GNOME alre
Joe Marcus Clarke wrote:
> What I'd like to achieve is a simple out-of-the-box way of mounting
> media such as CDs, and floppy disks without users necessarily needing to
> know about sysctl. While I can't speak for KDE, I know GNOME already
> has the ability to detect user-mountable media, and giv
On Mon, 3 Apr 2006, Joe Marcus Clarke wrote:
I would suggest that an extremely careful security audit of the userspace
and kernel mount and unmount code is due -- especially things like the
per-filesystem mount code (mount_nfs, etc). I'm not against the principle
of this though.
Agreed. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Watson wrote:
> On Mon, 3 Apr 2006, Joe Marcus Clarke wrote:
>
>> I know we have vfs.usermount, but this is not always sufficient since
>> the user has to own the mount point in question. What I propose is to
>> add a ``user'' mount option à l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Colin Percival wrote:
> Joe Marcus Clarke wrote:
>> I know we have vfs.usermount, but this is not always sufficient since
>> the user has to own the mount point in question. What I propose is to
>> add a ``user'' mount option à la Linux. This would m
On Mon, 3 Apr 2006, Joe Marcus Clarke wrote:
I know we have vfs.usermount, but this is not always sufficient since the
user has to own the mount point in question. What I propose is to add a
``user'' mount option à la Linux. This would make mount and umount setuid
root, but would allow much
On Mon, 3 Apr 2006, Joe Marcus Clarke wrote:
I know we have vfs.usermount, but this is not always sufficient since
the user has to own the mount point in question. What I propose is to
add a ``user'' mount option ? la Linux. This would make mount and
umount setuid root, but would allow much m
Simon L. Nielsen wrote:
> Any reason you can't just use sudo... ?
Because we are talking about desktop users. There are many ways to let
user mount devices, but nothing that works oob (or at least with very
few changes) with all desktop environments. Few of them allow to mount
removable media with
On 2006.04.03 01:32:36 -0400, Joe Marcus Clarke wrote:
> I know we have vfs.usermount, but this is not always sufficient since
> the user has to own the mount point in question. What I propose is to
> add a ``user'' mount option à la Linux. This would make mount and
> umount setuid root, but woul
Colin Percival wrote:
> Generally speaking it's much better to add a new setuid program which does
> exactly what you need, rather than making an existing and possibly insecure
> program setuid.
Generally speaking I agree with you. To minimize the impact of having to
run a different 'mount' execut
Joe Marcus Clarke wrote:
> I know we have vfs.usermount, but this is not always sufficient since
> the user has to own the mount point in question. What I propose is to
> add a ``user'' mount option à la Linux. This would make mount and
> umount setuid root, but would allow much more flexibility
Hi Joe,
On Mon, 3 Apr 2006, 01:32-0400, Joe Marcus Clarke wrote:
> I know we have vfs.usermount, but this is not always sufficient since
> the user has to own the mount point in question. What I propose is to
> add a ``user'' mount option ? la Linux. This would make mount and
> umount setuid ro
Joe Marcus Clarke wrote:
> I know we have vfs.usermount, but this is not always sufficient since
> the user has to own the mount point in question. What I propose is to
> add a ``user'' mount option à la Linux. This would make mount and
> umount setuid root, but would allow much more flexibility
В сообщении от Понедельник 03 Апрель 2006 12:32 Joe Marcus Clarke написал(a):
> I know we have vfs.usermount, but this is not always sufficient since
> the user has to own the mount point in question. What I propose is to
> add a ``user'' mount option à la Linux. This would make mount and
> umoun
I know we have vfs.usermount, but this is not always sufficient since
the user has to own the mount point in question. What I propose is to
add a ``user'' mount option à la Linux. This would make mount and
umount setuid root, but would allow much more flexibility when it comes
to removable media
34 matches
Mail list logo
