Bug#612918: Writing to /etc/ from a "privileged" UI
David Paleino 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-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612918: 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 [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
Bug#612918: Writing to /etc/ from a "privileged" UI
On Mon, 9 May 2011 09:45:41 -0400, Marvin Renich wrote: > * David Paleino [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
Bug#612918: Writing to /etc/ from a "privileged" UI
* David Paleino [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-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612918: 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
