Justin Pryzby <[EMAIL PROTECTED]> wrote:
> Indeed, I heard you the first two times, as, I suspect, did the other
> 83 people on the -rc ML.
>
> It is sometimes difficult to describe all the conditions leading up to
> a problem, so we appreciate your patience.
Having to repeat things a few
On Wed, Feb 23, 2005 at 02:59:21PM -0800, Tyler MacDonald wrote:
> > It is still not proven that this error can be reproduced w/o using root
> > privileges -
>
> To repo - I have done this *4* times now:
Indeed, I heard you the first two times, as, I suspect, did the other
83 people on the
Andreas Barth <[EMAIL PROTECTED]> wrote:
> Can a normal user kill mount, or do you need superuser privileges for
> that?
Andi,
I repoed this, including killing mount, as a normal user.
- Tyler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
* Tyler MacDonald ([EMAIL PROTECTED]) [050224 00:25]:
> > It is still not proven that this error can be reproduced w/o using root
> > privileges -
>
> To repo - I have done this *4* times now:
>
> - Get a cdrom with "user" mount permissions in fstab.
>
> - Put a cd in the tray
tags 296201 - unreproducible
tags 296201 + patch
thanks
This *is* reproducible, although I think one should always avoid doing a
"kill -9" if not really really absolutely necessary.
And I have suggested a patch in a previous message.
Cheers,
- Stephan.
Am Wed, 23. February 2005 um 14:59:2
> It is still not proven that this error can be reproduced w/o using root
> privileges -
To repo - I have done this *4* times now:
- Get a cdrom with "user" mount permissions in fstab.
- Put a cd in the tray. Leave the tray open so you have some extra
time.
- Op
> * Stephan Niemz ([EMAIL PROTECTED]) [050223 22:40]:
> > ln -sf ../proc/mounts mtab
Am Wed, 23. February 2005 um 22:43:45 +0100 schrieb Andreas Barth:
> There are multiple reasons why this is a bad idea - and even if not,
I'm curious, what are these multiple reasons? I've had no pro
severity 296201 important
tags 296201 + unreproducible
thanks
* Stephan Niemz ([EMAIL PROTECTED]) [050223 22:40]:
> There is quite a simple solution to this problem:
>
> ln -sf ../proc/mounts mtab
>
> Maybe this could be added to postinst or similar. Of course this
> only work
There is quite a simple solution to this problem:
ln -sf ../proc/mounts mtab
Maybe this could be added to postinst or similar. Of course this
only works when procfs is mounted to /proc, but is anyone really not
doing this nowadays?
The other advantage is that "mount" and "df
* Justin Pryzby ([EMAIL PROTECTED]) [050221 16:40]:
> I can't reproduce this. mount.c:856 blocks all signals, then tries to
> mount the fs, then updates mtab, then unblocks signals. I tested and
> this appears to ensure atomicity of the mount,mtab block WRT signals.
This won't help if you e.g. m
Justin Pryzby <[EMAIL PROTECTED]> wrote:
> I can't reproduce this. mount.c:856 blocks all signals, then tries to
> mount the fs, then updates mtab, then unblocks signals. I tested and
> this appears to ensure atomicity of the mount,mtab block WRT signals.
Jason, I just did it again:
On Mon, Feb 21, 2005 at 09:14:42AM -0500, pryzbyj wrote:
> On Sun, Feb 20, 2005 at 03:59:20PM -0800, Tyler MacDonald wrote:
> > Package: mount
> > Version: 2.12p-2
> > Severity: grave
> > Justification: user security hole
> >
> >
> > If a non-root user mounts media (in my case, a CD-ROM), and att
On Sun, Feb 20, 2005 at 03:59:20PM -0800, Tyler MacDonald wrote:
> Package: mount
> Version: 2.12p-2
> Severity: grave
> Justification: user security hole
>
>
> If a non-root user mounts media (in my case, a CD-ROM), and attempts
> to kill the process (in my case, a mad combination of ^C and ^\),
Package: mount
Version: 2.12p-2
Severity: grave
Justification: user security hole
If a non-root user mounts media (in my case, a CD-ROM), and attempts to kill
the process (in my case, a mad combination of ^C and ^\), the filesystem can
be mounted, yet not appear in /etc/mtab.
This means that whe
14 matches
Mail list logo
