Bug 135801 - constant annoyance with attempts to moun disks.
Summary: constant annoyance with attempts to moun disks.
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-volume-manager
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: John (J5) Palmieri
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-15 04:14 UTC by Michal Jaegermann
Modified: 2013-03-13 04:46 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-15 18:43:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2004-10-15 04:14:49 UTC
Description of problem:

I am not sure if this is really 'hal' but I am not sure what
is this 'manager.c' which produces these messages:

manager.c/982: mount_all: mounting /dev/sda1
mount: only root can mount /dev/sda1 on /media/scsidisk6
manager.c/982: mount_all: mounting /dev/sda2
mount: only root can mount /dev/sda2 on /media/scsidisk5
manager.c/982: mount_all: mounting /dev/sda3
mount: only root can mount /dev/sda3 on /media/scsidisk4
manager.c/982: mount_all: mounting /dev/sda6
mount: only root can mount /dev/sda6 on /media/scsidisk3
manager.c/982: mount_all: mounting /dev/sda7
mount: only root can mount /dev/sda7 on /media/scsidisk2
manager.c/982: mount_all: mounting /dev/sda8
mount: only root can mount /dev/sda8 on /media/scsidisk1
manager.c/982: mount_all: mounting /dev/sda9
mount: only root can mount /dev/sda9 on /media/scsidisk

Very good!  These are clearly marked 'noauto', and no other options,
and there are __not supposed__ to be mounted and definitely that is
the case for non-root.  So why all this racket?  Actually the fact
that they get mounted when 'root' is loging to a desktop, and they
have to be constantly unmounted, is a bug.  Not a show-stopper but a
getting on nerves inconvenience.

Comment 1 David Zeuthen 2004-10-15 13:03:11 UTC
Reassigning to gnome-volume-manager and John P.

> These are clearly marked 'noauto'

Which are put in by fstab-sync from hal such that such entries aren't
mounted at startup. This doesn't imply they shouldn't be mounted when
a desktop session starts.

Michal, I'm interested if you see any security issues with this?

This, btw, can be disabled in the g-v-m capplet (Hat
Menu->Applications->Preferences->Removable Storage) by disabling
automounting all together. FYI there have been complaints upstream
about this as well
 http://mail.gnome.org/archives/utopia-list/2004-September/msg00009.html

so disabling might be an option; John?

> Actually the fact that they get mounted when 'root' is
> loging to a desktop, and they have to be constantly 
> unmounted, is a bug.

Actually g-v-m unmounts all volumes mounted during the session on
logout, but, OK, if your session dies they are not. Another thing is
that it is discouraged to login to the GNOME desktop as root but that
is another matter.


Comment 2 Michal Jaegermann 2004-10-15 18:20:07 UTC
> Which are put in by fstab-sync from hal such that such entries aren't
> mounted at startup.

More precisely I edited them out from an insane garbage dumped
into my /etc/fstab by fstab-sync.  I cannot remove them entirely
because then they will be recreated in their former glory.

> This doesn't imply they shouldn't be mounted when
> a desktop session starts.

Yes, it does!  Currently existing entries in /etc/fstab _prevent_
mounting these by non-root users.  Quite on purpose and there
is not a shred of a reason to complain about that. If I would
want them to be mounted then I would have asked for this.
I specifically DO NOT WANT them to be mounted and second-guessing
my intentions is not doing any good.

> Michal, I'm interested if you see any security issues with this?

Well, I wrote explicitely "Not a show-stopper but a getting on
nerves inconvenience".  But there is actually a security angle
to that.  If you are bombarding users with a noise then they
quickly stop paying attention to any messages of that sort and
notifications about real problems are likely not to be noticed.
This is _not_ an invented problem as anyone with a real life
experience can attest.

> This, btw, can be disabled in the g-v-m capplet (Hat
> Menu->Applications->Preferences->Removable Storage) by disabling
> automounting all together.

In other words all or nothing?  Not very appealing but if you
do not have anything better to offer ....

Is this under a control of individual accounts only or also
overridable by a system administrator?  If the later control is
absent then this is basically worthless especially if it is
defaulting to an unsafe behaviour.  Just asking.

On one hand we are seeing SELinux, with all configuration and 
access control headaches that entails, and on the other hand
stuff like the above.  A very strange schizofrenia.


Comment 3 John (J5) Palmieri 2004-10-15 18:43:36 UTC
>> Which are put in by fstab-sync from hal such that such entries aren't
>> mounted at startup.
>
>More precisely I edited them out from an insane garbage dumped
>into my /etc/fstab by fstab-sync.  I cannot remove them entirely
>because then they will be recreated in their former glory.

If you have specific complaints please air them but this is just noise
above.  With the current release of HAL you can set policy to not
write out specific devices or write them out with the fstab flags you
would find sane.  It is very fine grain.

>> This doesn't imply they shouldn't be mounted when
>> a desktop session starts.
>
>Yes, it does!  Currently existing entries in /etc/fstab _prevent_
>mounting these by non-root users.  Quite on purpose and there
>is not a shred of a reason to complain about that. If I would
>want them to be mounted then I would have asked for this.
>I specifically DO NOT WANT them to be mounted and second-guessing
>my intentions is not doing any good.

David was refering to the noauto flag.  Its only purpose in life is to
make sure a drive is not mounted on boot.  HAL will not second guess
you as fstab-sync policy has been added for fine grain lockdown of
removable devices.

>> Michal, I'm interested if you see any security issues with this?
>
>Well, I wrote explicitely "Not a show-stopper but a getting on
>nerves inconvenience".  But there is actually a security angle
>to that.  If you are bombarding users with a noise then they
>quickly stop paying attention to any messages of that sort and
>notifications about real problems are likely not to be noticed.
>This is _not_ an invented problem as anyone with a real life
>experience can attest.

I can say the same for your style of bug reports.  As I said I am
interested in your complaints but it makes it much easier to get
through if the noise is kept down to a minimum and the actual
substance of the complaints are aired.

>> This, btw, can be disabled in the g-v-m capplet (Hat
>> Menu->Applications->Preferences->Removable Storage) by disabling
>> automounting all together.
>
>In other words all or nothing?  Not very appealing but if you
>do not have anything better to offer ....
>
>Is this under a control of individual accounts only or also
>overridable by a system administrator?  If the later control is
>absent then this is basically worthless especially if it is
>defaulting to an unsafe behaviour.  Just asking.

This is totaly controlable by the sysadmin.  You can define how drives
are mounted though the fstab-sync policy and you can edit the default
schema's for gnome-volume-manager to set automounting to false.

>On one hand we are seeing SELinux, with all configuration and 
>access control headaches that entails, and on the other hand
>stuff like the above.  A very strange schizofrenia.

There is no one usecase so we need to be flexable.

Anyway most of your complaints for HAL are already addressed in the
current rawhide packages though I would wait until tomorrow to upgrade
because David is fixing a bug that showed up with the new kernel today
(older kernels work fine).  As for gnome-volume-manager trying to
mount root partitions I am going to file this upstream.  As you said
yourself it is not a critical bug and we are in a freeze right now. 
The best solution is to turn automounting off by default.  If a patch
comes soon I might be able to sneak it in.

Moving upstream.

Comment 4 John (J5) Palmieri 2004-10-15 18:56:25 UTC
Upstream bug:
http://bugzilla.gnome.org/show_bug.cgi?id=155532

Comment 5 Michal Jaegermann 2004-10-15 19:51:44 UTC
I think that in all these explanations the real sense of my
report got lost.  Let me restate.

The problem as I see it is as follows.  Something (as I wrote I am
not sure what that really is, maybe 'hal', maybe something else, but
that is a detail) finds in /etc/fstab an entry with options which
are not allowing that something to mount the file file system
in question.  How this entry got there is really at this moment
immaterial.  Now instead of noting to iself "ok, this is not mine;
lets move on" this something spills, directly or indirectly,

mount: only root can mount  <whatever>

The only reaction to that can be "Doh!  Yes, we know that and
we want it that way."   Debugging messages are great in a development
phase but we are pretty close to a release now.  If you prefer
this is about a quality of implementation.

If you are trying to say that newer versions of whatever is
involved here are not doing the above anymore the this is great
and the problem is solved.  Otherwise I think that there are
still some loose ends.  I had no opportunity yet to see that for
myself.



Note You need to log in before you can comment on or make changes to this bug.