Re: Writing to /etc/ from a privileged UI
On Wed, May 11, 2011 at 10:15:48PM +0100, Dominic Hargreaves wrote: On Wed, May 11, 2011 at 10:54:16PM +0200, Adam Borowski wrote: On Wed, May 11, 2011 at 10:05:40PM +0200, Frank Küster wrote: Not at the same time, but someone might allow a user of a laptop to access their WLAN, but neither accept that an other user of the laptop should be able to use the same network without asking, nor that the keys be written in a system-wide configuration file. Sorry but if you alternate physical possession of a laptop with someone whom you suspect of being hostile, no files are secure as long as they're stored on that laptop. This is not necessarily the case if a per-user encrypted filestore, such as ecryptfs, is in use (where a user may be unlocking access to their home directory at the same time as logging in, via a pam hook). Ecryptfs is good at protecting user data in case of stolen hardware but in case of alternate physical possession, it is not much of protection. All it requires is to set up one daemon running as root to copy your data with different permission automatically after you log-in to your account and hand it back to you. Not even kernel trick is needed for this and very simple. But if you are protecting your kids from accessing uncontrolled network, may be simple solution such as making some configuration file unreadable by other normal user may be sufficient. Adding some logging od your kids account activity may be another good practice. Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110724063713.ga19...@debian.org
Re: Writing to /etc/ from a privileged UI
David Paleino da...@debian.org writes: Hello everybody, I'm writing this mail to gather comments about a serious bug I received some time ago, for which I haven't yet had time to make a proper fix. The bug is #612918, against wicd, Uses /etc/wicd/wireless-settings.conf as state file. My opinion is that wireless networks with some kind of configuration provided (say, a key, or a DNS server, or some static IP, [..]), should be saved there (so the bug really is: «don't uselessly save all the networks you encounter» -- and I already have a fix for that). The reporter's opinion is that no GUI should ever write to /etc/. However, WICD clients are run from privileged users, i.e. those in the `netdev' group, and are added there by root. So I think that's perfectly fine. With / being mounted read-only, and yes there are more and more people who do have that again, /etc is not writable at runtime for anything. So your GUI will simply fail to work. I took a look at how NetworkManager handles that: it stores configuration using gconf, so it's not really comparable. I'd like to stick with files under /etc/, possibly. What's your opinion on this? I haven't searched thoroughly through the archive, but I guess there are other UIs run by privileged non-root users that write to /etc/? Didier, I hope I correctly summarised the bug you reported. If not, please reply :) Thanks for your suggestions, David The only way you can argue is that your GUI is a nice frontend for editing the static config in /etc/wicd/wireless-settings.conf. As such the admin needs to remount / read-write before running it just like he would before running 'sensible-editor /etc/wicd/wireless-settings.conf'. In that case you should detect when /etc is read-only and have good error messages. Maybe even have some way to automatically or with one click mount / read-write for the duration of the write. Note: For comparison in apt one can configure hooks to mount / read-write before invoking dpkg and read-only after. So apt-get upgrade works without having to remount / read-write first. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iptfga36.fsf@frosties.localnet
Re: Writing to /etc/ from a privileged UI
Adam Borowski kilob...@angband.pl wrote: On Wed, May 11, 2011 at 10:05:40PM +0200, Frank Küster wrote: Not at the same time, but someone might allow a user of a laptop to access their WLAN, but neither accept that an other user of the laptop should be able to use the same network without asking, nor that the keys be written in a system-wide configuration file. Sorry but if you alternate physical possession of a laptop with someone whom you suspect of being hostile, no files are secure as long as they're stored on that laptop. In addition to the remarks of the others: It's not just about me as the laptop user trusting or not trusting other laptop users. I was rather thinking about a network owner allowing a particular person to use their access point, after being trained in the local policy and - what is more important to a certain type of staff - having signed and accepted that policy. The policy will probably contain a may not give a third party access to the information... Regards, Frank -- Frank Küster Vorstand B90/Grüne OV Miltenberg und Umgebung VCD Miltenberg, ADFC Aschaffenburg-Miltenberg Debian Developer (TeXLive) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4dv66t8@alhambra.kuesterei.ch
Re: Writing to /etc/ from a privileged UI
Jan Hauke Rahm j...@debian.org wrote: On Mon, May 09, 2011 at 04:59:39PM +0200, David Paleino wrote: On Mon, 9 May 2011 09:45:41 -0400, Marvin Renich wrote: Actually, one normal user should not be able to override the admin defaults for another user, so if there is already an entry in /etc, wicd should place any user change to that entry in ~user, but new, non-conflicting entries should go in /var/lib. Then, the order of preference should be ~user, /etc, /var/lib. I can't understand all this. Network connections are system-wide by their own nature -- or do you know cases where there could be different concurrent connections used by different users? No. Not at the same time, but someone might allow a user of a laptop to access their WLAN, but neither accept that an other user of the laptop should be able to use the same network without asking, nor that the keys be written in a system-wide configuration file. Regards, Frank -- Frank Küster Vorstand B90/Grüne OV Miltenberg und Umgebung VCD Miltenberg, ADFC Aschaffenburg-Miltenberg Debian Developer (TeXLive) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei456m0b@alhambra.kuesterei.ch
Re: Writing to /etc/ from a privileged UI
On Wed, May 11, 2011 at 10:05:40PM +0200, Frank Küster wrote: Not at the same time, but someone might allow a user of a laptop to access their WLAN, but neither accept that an other user of the laptop should be able to use the same network without asking, nor that the keys be written in a system-wide configuration file. Sorry but if you alternate physical possession of a laptop with someone whom you suspect of being hostile, no files are secure as long as they're stored on that laptop. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110511205416.ga1...@angband.pl
Re: Writing to /etc/ from a privileged UI
On Wed, May 11, 2011 at 10:54:16PM +0200, Adam Borowski wrote: On Wed, May 11, 2011 at 10:05:40PM +0200, Frank Küster wrote: Not at the same time, but someone might allow a user of a laptop to access their WLAN, but neither accept that an other user of the laptop should be able to use the same network without asking, nor that the keys be written in a system-wide configuration file. Sorry but if you alternate physical possession of a laptop with someone whom you suspect of being hostile, no files are secure as long as they're stored on that laptop. This is not necessarily the case if a per-user encrypted filestore, such as ecryptfs, is in use (where a user may be unlocking access to their home directory at the same time as logging in, via a pam hook). Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110511211547.gw4...@urchin.earth.li
Re: Writing to /etc/ from a privileged UI
On Wed, May 11, 2011 at 10:54:16PM +0200, Adam Borowski wrote: On Wed, May 11, 2011 at 10:05:40PM +0200, Frank Küster wrote: Not at the same time, but someone might allow a user of a laptop to access their WLAN, but neither accept that an other user of the laptop should be able to use the same network without asking, nor that the keys be written in a system-wide configuration file. Sorry but if you alternate physical possession of a laptop with someone whom you suspect of being hostile, no files are secure as long as they're stored on that laptop. My wireless network uses a RADIUS server to authenticate people against the network Kerberos database. Every user must have an entry in the Kerberos database in order to access the network. While I don't mind if while I'm connected to the network my partner uses the network connection, I certainly don't want him able to access the password that is used for authentication. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Writing to /etc/ from a privileged UI
On Wed, 11 May 2011, Dominic Hargreaves wrote: Sorry but if you alternate physical possession of a laptop with someone whom you suspect of being hostile, no files are secure as long as they're stored on that laptop. This is not necessarily the case if a per-user encrypted filestore, such as ecryptfs, is in use (where a user may be unlocking access to their home directory at the same time as logging in, via a pam hook). I suppose you do have done the non-trivial steps required to secure the box against a rogue kernel install by the 'untrusted' person? This is only one possible attack vector. There are others. There are defenses, but they go way beyond 'a per-user encrypted filesystem'. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110512012603.gb31...@khazad-dum.debian.net
Re: Writing to /etc/ from a privileged UI
Henrique de Moraes Holschuh h...@debian.org writes: On Wed, 11 May 2011, Dominic Hargreaves wrote: This is not necessarily the case if a per-user encrypted filestore, such as ecryptfs, is in use (where a user may be unlocking access to their home directory at the same time as logging in, via a pam hook). I suppose you do have done the non-trivial steps required to secure the box against a rogue kernel install by the 'untrusted' person? This is only one possible attack vector. There are others. There are defenses, but they go way beyond 'a per-user encrypted filesystem'. While this is all of course correct from a theoretical security standpoint, and these are all things one needs to care about if hardening a system against arbitrary attackers, a lot of real-life security isn't like that. There's often a good bit of merit in making reading private data reasonably difficult but not bothering making it impossible when the attacks one is worried about are casual snooping or accidental eavesdropping as opposed to concerted effort. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hb90u1ya@windlord.stanford.edu
Writing to /etc/ from a privileged UI
Hello everybody, I'm writing this mail to gather comments about a serious bug I received some time ago, for which I haven't yet had time to make a proper fix. The bug is #612918, against wicd, Uses /etc/wicd/wireless-settings.conf as state file. My opinion is that wireless networks with some kind of configuration provided (say, a key, or a DNS server, or some static IP, [..]), should be saved there (so the bug really is: «don't uselessly save all the networks you encounter» -- and I already have a fix for that). The reporter's opinion is that no GUI should ever write to /etc/. However, WICD clients are run from privileged users, i.e. those in the `netdev' group, and are added there by root. So I think that's perfectly fine. I took a look at how NetworkManager handles that: it stores configuration using gconf, so it's not really comparable. I'd like to stick with files under /etc/, possibly. What's your opinion on this? I haven't searched thoroughly through the archive, but I guess there are other UIs run by privileged non-root users that write to /etc/? Didier, I hope I correctly summarised the bug you reported. If not, please reply :) Thanks for your suggestions, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Writing to /etc/ from a privileged UI
On Mon, 9 May 2011 09:39:07 +0200, David Paleino wrote: ... Gah, I clicked Reply instead of Compose. Sorry everybody. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Writing to /etc/ from a privileged UI
On Mon, May 09, 2011 at 09:39:07AM +0200, David Paleino wrote: Hello everybody, I'm writing this mail to gather comments about a serious bug I received some time ago, for which I haven't yet had time to make a proper fix. The bug is #612918, against wicd, Uses /etc/wicd/wireless-settings.conf as state file. My opinion is that wireless networks with some kind of configuration provided (say, a key, or a DNS server, or some static IP, [..]), should be saved there (so the bug really is: «don't uselessly save all the networks you encounter» -- and I already have a fix for that). The reporter's opinion is that no GUI should ever write to /etc/. However, WICD clients are run from privileged users, i.e. those in the `netdev' group, and are added there by root. So I think that's perfectly fine. I took a look at how NetworkManager handles that: it stores configuration using gconf, so it's not really comparable. I'd like to stick with files under /etc/, possibly. What's your opinion on this? I haven't searched thoroughly through the archive, but I guess there are other UIs run by privileged non-root users that write to /etc/? /etc may include only _static_ configuration. What you have is variable state which belongs in /var. It's no different from a database, or dpkg's status data. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110509091253.ga7...@angband.pl
Re: Writing to /etc/ from a privileged UI
On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote: /etc may include only _static_ configuration. What you have is variable state which belongs in /var. It's no different from a database, or dpkg's status data. Static IPs, DNS servers and WEP/WPA keys for a given wireless network are variable state? Sorry, I disagree. I already said that I have a patch not to save networks for which no configuration is made -- which is the variable state thing at the moment. The question was different :) David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Writing to /etc/ from a privileged UI
On Mon, 09 May 2011 at 09:39:07 +0200, David Paleino wrote: I took a look at how NetworkManager handles that: it stores configuration using gconf, so it's not really comparable NM can go either way - it'll use the current user's gconf for connections that are not shared with other users, which is the default, or flat files in /etc for connections that are shared. I seem to remember newer NM versions (in experimental) have changed the default to be the other way round, on the basis that network connections are system-wide, so their configuration should be system-wide too. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110509092121.gb28...@reptile.pseudorandom.co.uk
Re: Writing to /etc/ from a privileged UI
On Mon, 9 May 2011 10:21:21 +0100, Simon McVittie wrote: On Mon, 09 May 2011 at 09:39:07 +0200, David Paleino wrote: I took a look at how NetworkManager handles that: it stores configuration using gconf, so it's not really comparable NM can go either way - it'll use the current user's gconf for connections that are not shared with other users, which is the default, or flat files in /etc for connections that are shared. I seem to remember newer NM versions (in experimental) have changed the default to be the other way round, on the basis that network connections are system-wide, so their configuration should be system-wide too. That's what I tend to think as well. In the bugreport, I first thought about per-user configuration (something like ~/.config/wicd/...), but then I realised that it's non-sense, since network connections are system-wide AFAIK. David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Writing to /etc/ from a privileged UI
On Mon, May 09, 2011 at 09:39:07AM +0200, David Paleino wrote: Hello everybody, I'm writing this mail to gather comments about a serious bug I received some time ago, for which I haven't yet had time to make a proper fix. The bug is #612918, against wicd, Uses /etc/wicd/wireless-settings.conf as state file. My opinion is that wireless networks with some kind of configuration provided (say, a key, or a DNS server, or some static IP, [..]), should be saved there (so the bug really is: «don't uselessly save all the networks you encounter» -- and I already have a fix for that). The reporter's opinion is that no GUI should ever write to /etc/. However, WICD clients are run from privileged users, i.e. those in the `netdev' group, and are added there by root. So I think that's perfectly fine. Aside from privileges wicd needs or has to write in /etc, how does it handle read-only / (including /etc)? Does it fall back to /var? Hauke -- .''`. Jan Hauke Rahm j...@debian.org www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
Re: Writing to /etc/ from a privileged UI
On Mon, 9 May 2011 11:55:39 +0200, Jan Hauke Rahm wrote: Aside from privileges wicd needs or has to write in /etc, how does it handle read-only / (including /etc)? Does it fall back to /var? No. I haven't tried, but it should be able to connect without a writable /(etc) (it already uses /var/lib/wicd/ to store runtime config): network configuration will just be lost on wicd-daemon shutdown. Still, I'll need to confirm this (maybe it'll throw an exception when trying to write the config files), and eventually fix it to support at least this behaviour. Is there some document I should be reading? :) -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Writing to /etc/ from a privileged UI
* David Paleino da...@debian.org [110509 04:19]: On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote: /etc may include only _static_ configuration. What you have is variable state which belongs in /var. It's no different from a database, or dpkg's status data. Static IPs, DNS servers and WEP/WPA keys for a given wireless network are variable state? Sorry, I disagree. I already said that I have a patch not to save networks for which no configuration is made -- which is the variable state thing at the moment. The question was different :) This isn't about whether the data saved in the config file is variable, it is about whether the config file is variable. Files in /etc should only be modified when the sysadmin is doing what (s)he considers to be configuration, not when a user is running a program. The specific data shown in the bug report is clearly variable state information and not static configuration info, but even adding and removing more permanent wireless access point info should not be done in /etc during the normal, continuous operation of a daemon. If I were designing the config structure, since each AP is a distinct entity that doesn't depend on any other AP (maybe that should be essid, not AP), I would have a .d directory where each essid had its own config file. There could be corresponding /etc/wicd/something.d and /var/lib/wicd/something.d directories. The admin could place files in /etc that he didn't want users messing with. Non-conflicting files in /etc, /var/lib, and ~user/.wicd (or better, ~user/.config/wicd), would be treated equally by wicd, with preference to ~user/.config/wicd then /var/lib/wicd, then /etc/wicd for any conflicting entries. Actually, one normal user should not be able to override the admin defaults for another user, so if there is already an entry in /etc, wicd should place any user change to that entry in ~user, but new, non-conflicting entries should go in /var/lib. Then, the order of preference should be ~user, /etc, /var/lib. Transient state information, like signal strength and quality should _not_ go in these files, but rather in /var/run/wicd/ (soon to be /run/wicd/). ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110509134541.gb...@cleo.wdw
Re: Writing to /etc/ from a privileged UI
On Mon, 9 May 2011 09:45:41 -0400, Marvin Renich wrote: * David Paleino da...@debian.org [110509 04:19]: On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote: /etc may include only _static_ configuration. What you have is variable state which belongs in /var. It's no different from a database, or dpkg's status data. Static IPs, DNS servers and WEP/WPA keys for a given wireless network are variable state? Sorry, I disagree. I already said that I have a patch not to save networks for which no configuration is made -- which is the variable state thing at the moment. The question was different :) This isn't about whether the data saved in the config file is variable, it is about whether the config file is variable. Files in /etc should only be modified when the sysadmin is doing what (s)he considers to be configuration, not when a user is running a program. So the CUPS web interface, and GNOME/KDE settings UIs, and such other things are all RC-buggy, because the info under /etc/ was not edited using vim/nano/emacs/... but through a UI? I repeat myself: users capable of running a wicd ui are enabled by root, by adding them to a specific system group (`netdev'). The specific data shown in the bug report is clearly variable state information and not static configuration info, [..] Again, I disagree. BSSID, ESSID, encryption key, automatic connection-flag all sound like configuration to me. Granted, there are more things to purge (channel and mode, for example), but that's a bug with a different solution than move everything to /var/. but even adding and removing more permanent wireless access point info should not be done in /etc during the normal, continuous operation of a daemon. Why not? It works. If I were designing the config structure, since each AP is a distinct entity that doesn't depend on any other AP (maybe that should be essid, not AP), I would have a .d directory where each essid had its own config file. There could be corresponding /etc/wicd/something.d and /var/lib/wicd/something.d directories. The admin could place files in /etc that he didn't want users messing with. Non-conflicting files in /etc, /var/lib, and ~user/.wicd (or better, ~user/.config/wicd), would be treated equally by wicd, with preference to ~user/.config/wicd then /var/lib/wicd, then /etc/wicd for any conflicting entries. Actually, one normal user should not be able to override the admin defaults for another user, so if there is already an entry in /etc, wicd should place any user change to that entry in ~user, but new, non-conflicting entries should go in /var/lib. Then, the order of preference should be ~user, /etc, /var/lib. I can't understand all this. Network connections are system-wide by their own nature -- or do you know cases where there could be different concurrent connections used by different users? Transient state information, like signal strength and quality should _not_ go in these files, but rather in /var/run/wicd/ (soon to be /run/wicd/). I probably haven't been clear enough. That's not configuration, and they shouldn't go in any config file. And that's already fixed. http://git.debian.org/?p=collab-maint/wicd.git;a=blob;f=debian/patches/34-dont_save_useless_config.patch There I drop 'quality', 'strength', 'bitrates' and 'has_profile' from the configuration file. As stated before in this mail, that list could include 'mode' and 'channel', but I prefer to be careful, since those are passed to iwconfig. Kindly, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Writing to /etc/ from a privileged UI
On Mon, May 09, 2011 at 11:29:07AM +0200, David Paleino wrote: On Mon, 9 May 2011 10:21:21 +0100, Simon McVittie wrote: I seem to remember newer NM versions (in experimental) have changed the default to be the other way round, on the basis that network connections are system-wide, so their configuration should be system-wide too. That's what I tend to think as well. In the bugreport, I first thought about per-user configuration (something like ~/.config/wicd/...), but then I realised that it's non-sense, since network connections are system-wide AFAIK. OTOH, credentials supplied to connect to a network can be user data. Indeed, having them as such means they can be protected (by using a keyring scheme like gnome-keyring, for example). Also encrypted $HOME is more common than encrypted /, I expect. multi-user and concurrent use are different things. If I loan my laptop to my brother, we are not concurrently changing system-wide network state; however, I may not want him to read my WPA passphrase and/or VPN connection details out of a file in /etc. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110509151316.ga10...@deckard.alcopop.org
Re: Writing to /etc/ from a privileged UI
On Mon, May 09, 2011 at 04:59:39PM +0200, David Paleino wrote: On Mon, 9 May 2011 09:45:41 -0400, Marvin Renich wrote: * David Paleino da...@debian.org [110509 04:19]: On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote: /etc may include only _static_ configuration. What you have is variable state which belongs in /var. It's no different from a database, or dpkg's status data. Static IPs, DNS servers and WEP/WPA keys for a given wireless network are variable state? Sorry, I disagree. I already said that I have a patch not to save networks for which no configuration is made -- which is the variable state thing at the moment. The question was different :) This isn't about whether the data saved in the config file is variable, it is about whether the config file is variable. Files in /etc should only be modified when the sysadmin is doing what (s)he considers to be configuration, not when a user is running a program. So the CUPS web interface, and GNOME/KDE settings UIs, and such other things are all RC-buggy, because the info under /etc/ was not edited using vim/nano/emacs/... but through a UI? I repeat myself: users capable of running a wicd ui are enabled by root, by adding them to a specific system group (`netdev'). You are right (I'd say). If I were designing the config structure, since each AP is a distinct entity that doesn't depend on any other AP (maybe that should be essid, not AP), I would have a .d directory where each essid had its own config file. There could be corresponding /etc/wicd/something.d and /var/lib/wicd/something.d directories. The admin could place files in /etc that he didn't want users messing with. Non-conflicting files in /etc, /var/lib, and ~user/.wicd (or better, ~user/.config/wicd), would be treated equally by wicd, with preference to ~user/.config/wicd then /var/lib/wicd, then /etc/wicd for any conflicting entries. Actually, one normal user should not be able to override the admin defaults for another user, so if there is already an entry in /etc, wicd should place any user change to that entry in ~user, but new, non-conflicting entries should go in /var/lib. Then, the order of preference should be ~user, /etc, /var/lib. I can't understand all this. Network connections are system-wide by their own nature -- or do you know cases where there could be different concurrent connections used by different users? No. What I like about (parts of) this solution is that /etc is kept a bit cleaner. For a few reasons (/etc being read-only, or being stored in a VCS) I like the idea of having /etc unmodified in normal circumstances. I completely agree with you that such data wicd stores has nothing to do in ~user. But the concept of two directories, one in /etc, one in /var, is something that appeals to me. The admin can still choose to copy files from /var over if he wants to keep them. If that really solves all use cases, I don't know. If it's the most practical approach, I don't know either. It's just something I'd like in wicd (if wicd then still works as well as it does now for me). Transient state information, like signal strength and quality should _not_ go in these files, but rather in /var/run/wicd/ (soon to be /run/wicd/). I probably haven't been clear enough. That's not configuration, and they shouldn't go in any config file. And that's already fixed. http://git.debian.org/?p=collab-maint/wicd.git;a=blob;f=debian/patches/34-dont_save_useless_config.patch There I drop 'quality', 'strength', 'bitrates' and 'has_profile' from the configuration file. As stated before in this mail, that list could include 'mode' and 'channel', but I prefer to be careful, since those are passed to iwconfig. I like that anyways. Hauke -- .''`. Jan Hauke Rahm j...@debian.org www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
Re: Writing to /etc/ from a privileged UI
On Mon, 9 May 2011 16:13:16 +0100, Jon Dowland wrote: On Mon, May 09, 2011 at 11:29:07AM +0200, David Paleino wrote: On Mon, 9 May 2011 10:21:21 +0100, Simon McVittie wrote: I seem to remember newer NM versions (in experimental) have changed the default to be the other way round, on the basis that network connections are system-wide, so their configuration should be system-wide too. That's what I tend to think as well. In the bugreport, I first thought about per-user configuration (something like ~/.config/wicd/...), but then I realised that it's non-sense, since network connections are system-wide AFAIK. OTOH, credentials supplied to connect to a network can be user data. Indeed, having them as such means they can be protected (by using a keyring scheme like gnome-keyring, for example). Also encrypted $HOME is more common than encrypted /, I expect. Or just proper permissions to the user-config directory. :) (I'd avoid adding more dependencies to wicd) multi-user and concurrent use are different things. If I loan my laptop to my brother, we are not concurrently changing system-wide network state; however, I may not want him to read my WPA passphrase and/or VPN connection details out of a file in /etc. Ok, this makes sense. So I could change the UI so that it provides a Save for all users checkbox, that makes it save data to /etc/wicd/, otherwise the data would be saved to ~/.config/wicd/. I just submitted a bug to myself, so I remember to implement this :) Kindly, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Writing to /etc/ from a privileged UI
On Mon, May 09, 2011 at 04:59:39PM +0200, David Paleino wrote: On Mon, 9 May 2011 09:45:41 -0400, Marvin Renich wrote: * David Paleino da...@debian.org [110509 04:19]: On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote: /etc may include only _static_ configuration. What you have is variable state which belongs in /var. It's no different from a database, or dpkg's status data. This isn't about whether the data saved in the config file is variable, it is about whether the config file is variable. Files in /etc should only be modified when the sysadmin is doing what (s)he considers to be configuration, not when a user is running a program. So the CUPS web interface, and GNOME/KDE settings UIs, and such other things are all RC-buggy, because the info under /etc/ was not edited using vim/nano/emacs/... but through a UI? CUPS: definitely. Most of its configuration is in reality persistent state which most certainly belongs under /var. This has been a major bug in CUPS since its inception. This includes all its queues, PPD files, and even dynamically updated parts of cupsd.conf. It definitely needs fixing, despite upstream's objection to that. Other admin tools may or may not be buggy (see below). There's a fuzzy area between static configuration (/etc) and persistent state (/var) [and there's also ephemeral state (/run)]. If it's generated by a program, it's most likely /not/ static. CUPS queue configuration is this type of data: on one hand one may create it by hand, but it can also be created and updated via lpadmin or via the web interface. The deciding factor for me here is that it also stores queue state in here--that makes it require /var. It could be split into static and dynamic parts split between /etc and /var, or just moved wholesale to /var. Static state is usually obvious stuff such as interfaces and port numbers to listen on. Dynamic state isn't always quite so obvious, but wireless AP info is certainly more on the persistent state side than static. It's still configuration, but it's not truly static configuration, and so it falls outside the remit of /etc. I repeat myself: users capable of running a wicd ui are enabled by root, by adding them to a specific system group (`netdev'). This is not relevant: /etc can not be considered to be writable by default, irrespective of the user/group making changes. The specific data shown in the bug report is clearly variable state information and not static configuration info, [..] but even adding and removing more permanent wireless access point info should not be done in /etc during the normal, continuous operation of a daemon. d Why not? It works. Read-only root is a goal we have had for a number of years. We'll actually be mostly there in the very near future with /run and mtab symlinking. Anything which writes to /etc during its normal operation is de facto broken and needs fixing (e.g. CUPS). Programs can not, and should not, expect to have a writable /etc under normal conditions. To clarify, programs such as editors and even custom tools to modify configuration are obviously needed to update configuration files under /etc. However, the admin may have been required to remount / read-write prior to using their tool-of-choice for making changes. Other than this usage, writing to /etc is bad practice. IMO it should be considered RC buggy for wheezy, and banned outright--it's fundamentally incompatible with a r/o rootfs. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
