All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Jim Dennis <jdennis@cadence.com>
Cc: autofs@linux.kernel.org
Subject: Re: nonroot umount
Date: Tue, 11 Jul 2006 19:12:27 -0400	[thread overview]
Message-ID: <x49wtajivms.fsf@redhat.com> (raw)
In-Reply-To: <920746F6DF728345915EF4D6DA610D0F0111249A@MAILSJ2.global.cadence.com> (Jim Dennis's message of "Tue, 11 Jul 2006 15:56:50 -0700")

==> Regarding Re: [autofs] nonroot umount; "Jim Dennis" <jdennis@cadence.com> adds:

jdennis> On Date: Tue, 11 Jul 2006 08:39:01 -0400
jdennis> Peter Staubach <staubach@redhat.com> wrote (in response to Marcos Diez
jdennis> <marcos@unitron.com.br>):

>> Marcos Diez wrote:

>>> In a Unix desktop system automount is very practical for CDROMs, 
>>> digital cameras, USB flash drives and any other type of removable
jdennis> media.
>>> But it is annoying to the unprivileged user to wait the timeout to 
>>> remove the media.

>> It seems to me that a better architected solution might be to tie in
jdennis> the automounter with the eject(1) sort of command.

>> It is not good for a user to have to know that he needs to zing the
jdennis> automounter in order to remove his media.

>> Thanx...
>> ps

jdennis>  So, perhaps we could send a patch to the maintainer of the eject
jdennis> utility.  It could detect if the target is
jdennis>  under an autofs and use this code in place of the ioctl() that it would
jdennis> normally send to a CD-ROM or similar
jdennis>  device.

jdennis>  On my OpenSuSE system eject is already marked SUID/root, though it
jdennis> doesn't seem the be the case for my RHEL4
jdennis>  system nor on my Debian system.

jdennis>  As usual I'd limit the risk of another SUID/root binary by marking the
jdennis> executable mode 4550 and associating
jdennis>  it with some relevant group (such as "console").  Thus only processes
jdennis> running in the specified group can attempt
jdennis>  to exploit any vulnerabilities in it.

jdennis>  Question: how would one programmatically detect that a particular
jdennis> mount point is being managed by an autofs process?

I simply don't like this idea.  ;)  As I mentioned before, there are better
mechanisms to deal with removable media.

If, however, you insist on using the automounter for this, then why not
specify a short timeout for removable media?  Put all forms of removable
media in the same map, and use --timeout=1 or 5, or 10, whatever suits
you.  Would that be an acceptable solution?

-Jeff

  reply	other threads:[~2006-07-11 23:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-11 22:56 nonroot umount Jim Dennis
2006-07-11 23:12 ` Jeff Moyer [this message]
     [not found] <200607100726.k6A7Po1e029994@hera.kernel.org>
2006-07-10 23:26 ` Marcos Diez
2006-07-11 12:39   ` Peter Staubach
2006-07-11 13:47     ` Jeff Moyer
2006-07-11 14:09       ` Peter Staubach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x49wtajivms.fsf@redhat.com \
    --to=jmoyer@redhat.com \
    --cc=autofs@linux.kernel.org \
    --cc=jdennis@cadence.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.