GNOME Bugzilla – Bug 681667
use the normal /etc/ppp/peers for connections
Last modified: 2012-08-24 14:02:51 UTC
Hi. As mentioned in #681666 already, I think it's very unfortunate, that NM breaks more or less with all the standard ways of configuring interfaces, or at least ignores them, trying to make all on its own. Not having any fancy stuff like NM, the traditional way for configuring modes (like broadband UMTS) has been ppp, with configurations for the PPP connections in /etc/ppp/peers and chatscripts for the modems in /etc/chatscripts. So may I suggest that you extend NM (or the respective plugin), so that it respects the normal ppp/chatscripts configuration from the system and offers the connections defined there. Of course these files are typically non-readable for the user, so they should only be shown and usable for a user if he has read access the files (which can be easily done for many users via group memberships or ACLs). Cheers, Chris.
Oh... and IMHO, NM should never allow the user to edit any of the system wide config files... These should be handled outside of NM and only be used for reading/exporting connections.
Actually, I would personally prefer if NetworkManager used some basic external tool for PPP like wvdial or something else. Like it does for DHCP (dhclient), like it does for wifi (wpa_supplicant). But it is entirely possible that this was not an option. But many users just use wvdial with success and these are advanced users. And these advanced users come up with working configurations, just as in wpa_supplicant. But, we can't compare NM's config with wvidal and fix things easily. But this is just my personal rant. I will appreciate more comments about how NetworkManager should support PPP processing in its primary use cases and in the corner cases where you need specific PPP tweaking.
Hi Pavel. 1) wvdial is (IIRC) also just some front end to ppp and uses that for it's actual workings, right? But maybe, it would make sense to "export" its configuration, too... But perhaps we should track that in another 2) I think NM should do the following with respect to ppp/chatscripts: a) The "Mobile Broadband" tab in the GUI is IMHO somewhat misleading or well at least these are usually "Modem connections" or "PPP connections". Anyway,.. the GUI would need a new category, either called "PPP connections" or something like this. b) Now what should NM do? - NM should read files in /etc/ppp/peers/*, the file name can be the connection name. Somehow monitoring that directory for additions (e.g. via inotify?) - IMHO the best would be if it simply issues pon "connection" and poff "connections" to do the actual work. - The problem is obviously, how to secure that a user can only use the connections he is allowed to. I personally tend to do this via filesystem permissions: a) e.g. Debian has a group "dip". If a user is in that group, he should be allowed all connections b) A user should further be allowed to use a connection, if he can read all necessary files; this is unfortunately a bit tricky: Possible files he need to read include (apart from /etc/ppp/peers/*) /etc/ppp/chap-secrets and/or /etc/ppp/pap-secrets But maybe further files as ppp scripts may invoke arbitrary stuff, e.g. connect '/usr/sbin/chat -v -f /etc/chatscripts/Vodafone' So the best thing IMHO, would be to simply run pon/poff as the respective user, and forget about all of the above. If the user is in any distro specific group like Debian's "dip" that will be granted,... also, if the user can read/write all necessary files and execute all necessary programs. So in short: - read /etc/ppp/peers/* for connection names - delegate all actual work to pon/poff (make some timeouts perhaps) - execute pon/poff as the user making the request to NM, thereby gaining the necessary security. Cheers, Chris.
> 1) wvdial is (IIRC) also just some front end to ppp and uses that for it's > actual workings, right? Correct. But it's configuration was good enough for many users who would never configure pppd themselves. And if I'm not mistaken, it was also good enough for OpenWRT tools. As I said, this is my personal remark, I'll try to ask other devs some time. > But maybe, it would make sense to "export" its configuration, too... > But perhaps we should track that in another Possibly. > 2) I think NM should do the following with respect to ppp/chatscripts: > > a) The "Mobile Broadband" tab in the GUI is IMHO somewhat misleading or well at > least these are usually "Modem connections" or "PPP connections". > Anyway,.. the GUI would need a new category, either called "PPP connections" or > something like this. This is the GUI stuff. That will be interesting later. > b) Now what should NM do? > - NM should read files in /etc/ppp/peers/*, the file name can be the connection NM is currently only reading its own configuration files and network scripts configuration files via plugins. I don't think NM will ever read configuration files for individual daemons, there's no reason for it as they are intended for pppd only. > name. Somehow monitoring that directory for additions (e.g. via inotify?) > > - IMHO the best would be if it simply issues pon "connection" and poff > "connections" to do the actual work. Then why use NM if you can use pppd? > - The problem is obviously, how to secure that a user can only use the > connections he is allowed to. > > I personally tend to do this via filesystem permissions: > a) e.g. Debian has a group "dip". > If a user is in that group, he should be allowed all connections > b) A user should further be allowed to use a connection, if he can read all > necessary files; this is unfortunately a bit tricky: > Possible files he need to read include (apart from /etc/ppp/peers/*) > /etc/ppp/chap-secrets and/or /etc/ppp/pap-secrets > But maybe further files as ppp scripts may invoke arbitrary stuff, e.g. > connect '/usr/sbin/chat -v -f /etc/chatscripts/Vodafone' This could be considered when you have a plan to support it. > So the best thing IMHO, would be to simply run pon/poff as the respective user, > and forget about all of the above. This could actually be a very simple type of connection with just name of the ppp config (and no other configuration). > If the user is in any distro specific group like Debian's "dip" that will be > granted,... also, if the user can read/write all necessary files and execute > all necessary programs. > > > So in short: > - read /etc/ppp/peers/* for connection names Reading just the names could be done with a special configuration plugin. It would be very simple and only read this type of connections. > - delegate all actual work to pon/poff (make some timeouts perhaps) Sure. > - execute pon/poff as the user making the request to NM, thereby gaining the > necessary security. This could be sorted out later. > Cheers, > Chris. So... now the proceeding will follow one of the following procedures: 1) A regular developer will find this feature so important that he starts implementing it. I don't actually thing any one will do that but I may be mistaken. 2) Someone else will start working on a patch while consulting with the devs so that it can be included. I don't know about anyone and even then it's not 100% sure it will get in. It might have better chance if it fits well with the current ppp framework. 3) I will eventually close the bug as WONTFIX just as I did with many other fun ideas that will not be implemented simply because there's nobody who would do that.
(In reply to comment #4) > NM is currently only reading its own configuration files and network scripts > configuration files via plugins. I don't think NM will ever read configuration > files for individual daemons, there's no reason for it as they are intended > for pppd only. Well I think the functionality I suggest in this bug SHOULD probably went into an plugin, right? And then you're fine,... no need for NM core to read foreign configuration file. So in the end, do what the ifupdown plugin does now with /etc/network/interfaces for the ppp config :) > > - IMHO the best would be if it simply issues pon "connection" and poff > > "connections" to do the actual work. > Then why use NM if you can use pppd? Yeah well, with that argument we can drop NM completely, can't we? ;) For everything, there's already some tool which can do it I though now the idea of NM is to concentrate configuration AND management in one place, right? So consider all of such plugins like the one for ifupdown, or the one I basically propose here for ppp, to allow: - to use "legacy" configuration (though I wouldn't consider it legacy) - or to act as a bridge for those people who want to retain "native" / "legacy" configuration ... but (in both cases) still benefit from the management features of NM. > > > So the best thing IMHO, would be to simply run pon/poff as the respective user, > > and forget about all of the above. > This could actually be a very simple type of connection with just name of the > ppp config (and no other configuration) Yep,... I think so, too. > > - execute pon/poff as the user making the request to NM, thereby gaining the > > necessary security. > This could be sorted out later. Sure, though I guess this is really an important part. Just consider you have some secured connection (VPN like) which, once you're connected, offers you (then) unauthorized access on resources. The encryption part is done by some smartcard (like a SIM card), where you need a PIN to use it. The PIN is stored in the ppp chatscript... (assumed to be only readable by allowed users). If we now export the connection (i.e. allow users to enable it) unconditionally we break quite some security ;) > 1) A regular developer will find this feature so important that he starts > implementing it. I don't actually thing any one will do that but I may > be mistaken. Don't know,... do they read this? Or can you tell/ask them? I mean we had these kinds of discussion in the other bug, and I don't want to repeat it ;) ,... I just think that NM developers should have some native interest in spending time on things like this ticket (even if they're personally not much interested) just to improve NM's acceptance. Just look at the thread about how to improve integration between NM/ifupdown I've started on the debian-devel mailing list... this nearly became a flame war and people came up with many concerts just like such things missing. And after all, as you said it's probably not too difficult to implement (for someone who is into the NM code already). > 2) Someone else will start working on a patch while consulting with the devs > so that it can be included. I don't know about anyone and even then > it's not 100% sure it will get in. It might have better chance if it fits well > with the current ppp framework. Currently I'm quite busy with other projects for the next monthts; maybe afterwards, but I'd have to read into NM code first. When I started reporting that tickets about improving integration I had my end-user hat on, and rather just wanted to get things which I won't be able to drop for sure work nicely with NM ;) > 3) I will eventually close the bug as WONTFIX just as I did with many other fun > ideas that will not be implemented simply because there's nobody who would do > that. Well I already told you that personally I think it's a bad idea to do this, because many ideas and discussion about things get's lost... and maybe in 10 years or so, someone would come up with time for this,... but everything's effectively gone then. Some projects have a special category for things like this... e.g. something like "SUSPENDED"... maybe you can add such a thing to your bugzilla. Cheers, Chris.
(In reply to comment #5) > (In reply to comment #4) > > NM is currently only reading its own configuration files and network scripts > > configuration files via plugins. I don't think NM will ever read configuration > > files for individual daemons, there's no reason for it as they are intended > > for pppd only. > Well I think the functionality I suggest in this bug SHOULD probably went into > an plugin, right? Could be, but I'm afraid you would also have to implement the core part to support this type of plugin. > And then you're fine,... no need for NM core to read foreign configuration > file. > So in the end, do what the ifupdown plugin does now with > /etc/network/interfaces for the ppp config :) :) > > > - IMHO the best would be if it simply issues pon "connection" and poff > > > "connections" to do the actual work. > > Then why use NM if you can use pppd? > Yeah well, with that argument we can drop NM completely, can't we? ;) In this case you only need it for the connect/disconnect UI integration. NM can do much more, though. > For everything, there's already some tool which can do it Unfortunately not. > I though now the idea of NM is to concentrate configuration AND management in > one place, right? And in one format :). > So consider all of such plugins like the one for ifupdown, or the one I > basically propose here for ppp, to allow: > - to use "legacy" configuration (though I wouldn't consider it legacy) > - or to act as a bridge for those people who want to retain "native" / "legacy" > configuration > ... but (in both cases) still benefit from the management features of NM. You're right. > > > > So the best thing IMHO, would be to simply run pon/poff as the respective user, > > > and forget about all of the above. > > This could actually be a very simple type of connection with just name of the > > ppp config (and no other configuration) > Yep,... I think so, too. > > > > > - execute pon/poff as the user making the request to NM, thereby gaining the > > > necessary security. > > This could be sorted out later. > Sure, though I guess this is really an important part. > Just consider you have some secured connection (VPN like) which, once you're > connected, offers you (then) unauthorized access on resources. > The encryption part is done by some smartcard (like a SIM card), where you need > a PIN to use it. > The PIN is stored in the ppp chatscript... (assumed to be only readable by > allowed users). > If we now export the connection (i.e. allow users to enable it) unconditionally > we break quite some security ;) Don't need to. > > 1) A regular developer will find this feature so important that he starts > > implementing it. I don't actually thing any one will do that but I may > > be mistaken. > Don't know,... do they read this? Or can you tell/ask them? I'm already pretty sure they won't. I'd have to also show them 100 other requests and they can just go and read through the bugzilla at any time. > I mean we had these kinds of discussion in the other bug, and I don't want to > repeat it ;) ,... I just think that NM developers should have some native > interest in spending time on things like this ticket Unfortunately not. > (even if they're personally not much interested) just to improve NM's accceptance. Help welcome. > Just look at the thread about how to improve integration between NM/ifupdown > I've started on the debian-devel mailing list... this nearly became a flame war > and people came up with many concerts just like such things missing. I can imagine. > And after all, as you said it's probably not too difficult to implement (for > someone who is into the NM code already). Just as another 100 things. > > 2) Someone else will start working on a patch while consulting with the devs > > so that it can be included. I don't know about anyone and even then > > it's not 100% sure it will get in. It might have better chance if it fits well > > with the current ppp framework. > Currently I'm quite busy with other projects for the next monthts; maybe > afterwards, but I'd have to read into NM code first. > When I started reporting that tickets about improving integration I had my > end-user hat on, and rather just wanted to get things which I won't be able to > drop for sure work nicely with NM ;) > > > > 3) I will eventually close the bug as WONTFIX just as I did with many other fun > > ideas that will not be implemented simply because there's nobody who would do > > that. > Well I already told you that personally I think it's a bad idea to do this, > because many ideas and discussion about things get's lost... This is NetworkManager bugzilla and it's used to maintain active bugreports. The bugs are not deleted, just closed. You can still link to them in your documents and there are many other places to put ideas on various things. > and maybe in 10 years or so, someone would come up with time for this,... but > everything's effectively gone then. Bugzilla is not a good tool for permanent document storage. > Some projects have a special category for things like this... e.g. something > like "SUSPENDED"... maybe you can add such a thing to your bugzilla. We already have this feature. You can use bugzilla search to find CLOSED/WONTFIX bug reports. Sorry for not meeting your expectations about NetworkManager bug maintainance. This bug can be reopened when we have at least some patches or they can be delivered by other means.