From: Mike Waychison <Michael.Waychison@Sun.COM>
To: Paul Jakma <paul@clubi.ie>
Cc: autofs@linux.kernel.org, raven@themaw.net
Subject: Re: submount vs automount
Date: Mon, 28 Jun 2004 12:25:55 -0400 [thread overview]
Message-ID: <40E04693.1010507@sun.com> (raw)
In-Reply-To: <Pine.LNX.4.60.0406281651490.13910@fogarty.jakma.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Jakma wrote:
> On Mon, 28 Jun 2004, Mike Waychison wrote:
>
>>> Why should the user on :0 be special?
>>
>>
>> Cause this is the kind of policy I'd like to see :)
>
>
> It doesnt make sense though. Eg, I remember in College the SPARCStation
> labs (for some reason) each only had one workstation with a floppy
> device. 9/10 the user using the floppy was not on :0.0.
>
> I can imagine something similar today with Zip/Jazz/DVR-RW+packet
> UDF/$CHIC_REMOVABLE_MEDIA_DE_JOUR.
>
This policy has to be determined on a machine-by-machine basis. I think
we can agree to that.
I just chose to examine the :0 policy because doing so allows us to
explore the implications of such an implementation.
For example, after considering the 'owner' bit, I realize now that
autofs would:
- - still have to parse for such an option as it runs as root and would
likely have to setuid to the user in question (so umount(8) still works).
- - which implies that automount would need to know who triggered the
mount, which isn't possible without a protocol jump.
Going back to earlier discussion, when Jim Carter discussed the
'first-acccess / mount-owner' scenario, I think there has to be a
compromise between security and functionality. Prescribing policies
such as ':0' helps enforce some level of security access to the medium,
while the 'no-policy policy' is just as bad as setups described above
where your fd device file is o+rw.
- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
http://www.sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA4EaTdQs4kOxk3/MRAmLJAJ9mrD33QJBrH63X6TAeWfAki9PMjACdEnZD
0gLuGLf4npMYOUPC8j+OzIA=
=vveZ
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2004-06-28 16:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-22 16:10 is there an autofs roadmap somewhere? Lever, Charles
2004-06-25 14:46 ` raven
2004-06-25 17:03 ` submount vs automount Jim Carter
2004-06-25 18:31 ` Mike Waychison
2004-06-26 0:19 ` Jim Carter
2004-06-28 1:32 ` Paul Jakma
2004-06-28 15:44 ` Mike Waychison
2004-06-28 15:46 ` Mike Waychison
2004-06-28 16:02 ` Paul Jakma
2004-06-28 15:59 ` Paul Jakma
2004-06-28 16:25 ` Mike Waychison [this message]
2004-06-28 17:00 ` Paul Jakma
2004-06-29 1:41 ` Ian Kent
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=40E04693.1010507@sun.com \
--to=michael.waychison@sun.com \
--cc=autofs@linux.kernel.org \
--cc=paul@clubi.ie \
--cc=raven@themaw.net \
/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.