[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lack of transparency of automatic actions



Am Freitag 13 Oktober 2006 17:18 schrieb John Goerzen:
> This has been bugging me for some time now, and I'd like to see if we
> can improve the situation.
>
> The main problem is that it's not clear how all this media
> autodection/automounting works.  It's not clear how to enable it, it's
> not clear how the permissions work, and it's not clear how to manage it.
>
> Let's start from the worst scenario: a system administrator.
> Traditionally, to know who can mount a device, you can look at
> /etc/fstab: if something is marked "user", then a user can mount it.
> You can also look at the permissions of the entry in /dev to see if a
> user can access it directly.

That is still the case

> Now, apparently, if a user is in the plugdev group, then that user could
> mount it even if it appears nowhere in fstab and even if the user
> doesn't have access to the /dev entry.  But this isn't documented
> anywhere obvious, certainly.  It should be in big capital letters
> somewhere.

No, he can only mount it if it is marked as a removable device _and_ if the 
device file has the proper permissions for the user

> Next, what about from the user's perspective?  By default, when you
> add a user, that user is not a member of plugdev, so these things don't
> work.  Gnome warns you that you need to be a member in some cases; KDE
> doesn't.  It would be nice for KDE to do that.

Not really, maybe some users are not supposed to able to do that? Shall those
be flodded with useless messages?

> It's also not clear how it reacts to devices that are in fstab, or how
> to make it shut up about stuff. 

It does. pmount honors the fstab entries, it just does not require them

> But worse -- what if you're not using Gnome or KDE?  I can find no way
> for a user that doesn't use any X applications to take advantage of this
> automatic support, even if the user is in the plugdev group.  I can't
> even find a way for a user to take advantage of it manually, again even
> if the user is in plugdev.  Why are we restricing this to users of GUIs?

There is pmount.

> Now, what about networking?  We have two competing systems: ifupdown and
> network-manager.  ifupdown works fine for static servers or
> workstations, but it doesn't do any of the automatic network scanning
> and connecting that network-manager does.

And network-manager is unable to connect to two networks at the same time, 
e.g. to one via cable and to one via WLAN. Very annoying, especially if only 
one of them routes to inet.

> It's great to have those   
> network-manager features -- automatically bringing up eth0 when a cable
> is plugged in, automatically connecting to a known wireless network,
> etc.  But network-manager only works for interfaces that don't have
> things specified in /etc/network/interfaces.  So I can't tell it to run
> an iwpriv command on my wireless card before scanning for networks.

"man NetworkManagerDispatcher" looks promising

> Even worse, you again have to use KDE or Gnome to take advantage of
> network-manager.  Why are we leaving CLI users out in the cold?

Good question. The concept for a cli like this would need many thoughts, 
though. A GUI makes that a bit easier.

> Moreover, it is completely unclear how permissions for taking network
> devices up and down are managed in this scenario.  Ordinarily, only root
> can do that, but now we're apparently letting anyone. How can we
> restrict that?

A user is a member of group netdev or not. Management goes with d-bus 
configuration files.

HS

Attachment: pgpEQWHdNcooT.pgp
Description: PGP signature


Reply to: