Re: Parallellizing the boot in Debian Squeeze - ready for wider testing
On 5/7/2010 2:33 AM, Paul Wise wrote: > Other distros are using upstart: > > http://upstart.ubuntu.com/ I thought Upstart was on the list for release in Sqeeze. Has this changed? http://lists.debian.org/debian-devel-announce/2009/09/msg3.html -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
UPG and the default umask
Debian, by default, utilizes the user private group scheme (UPG). This means that when a new user is created on a system, a group of the same name, if not already in place, is created, and the user is placed in the group, as the only user. Thus, when new files (dirs, etc) are created by that user, the group added to that new file is the UPG of the user. For example: # useradd foo # id foo uid=1000(foo) gid=1000(foo) groups=1000(foo) [snip] # su - foo $ touch newfile $ ls -l newfile -rw-r--r-- 1 foo foo 0 May 10 10:05 newfile So, the appropriate group is applied, and the user foo is the only member of the foo group. But, do you see a problem? The group permissions are 'r--', even though 'foo' is the only member of the 'foo' group. This means the umask is '0022'. If we change the default umask to '0002', then the appropriate permissions will be applied with the group: $ umask 0002 $ touch anotherfile $ ls -l anotherfile -rw-rw-r-- 1 foo foo 0 May 10 10:06 anotherfile As it sits, having the default umask set as '0022' isn't breaking anything, but it's no longer needed. It's just historical baggage coming from the 'users' group on older UNIX systems, where any new user added to the system was added to the 'users' group by default. Thus, removing the write bit made sense. It doesn't make any sense with UPG. For comparison's sake, Fedora (and as a result, RHEL/CentOS/etc) have implemented '0002' as their default umask, as they implement UPG. openSUSE and family, however, still use the 'users' group, so it makes sense for them to use '0022' for their value. I guess I'm more or less curious why we're still using this outdated umask value with UPG. What would it take for Debian to update our default umask to match the UPG scheme? Is this doable for Sqeeze? Are there reasons for not making the switch? Thanks, -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 5/10/2010 10:23 AM, Julien Cristau wrote: > On Mon, May 10, 2010 at 10:14:00 -0600, Aaron Toponce wrote: > Are there reasons for making the switch? With user groups, umask 002 or > 022 doesn't make a difference. To switch off user groups, you set > USERGROUPS=no in adduser.conf, and that's it. The biggest reason for making the change is when group collaboration becomes a necessity. Suppose you have an 'devel' group on the system, and a central directory where the collaboration happens. Because of the default umask value being '0022', the users must make sure that they have 'umask 0002' in their shell rc file, or as appropriate, or they must be constantly calling chmod to change the group permissions when new files are created. If the default umask is '0002' on a UPG system, then this checklist item doesn't need to be worried about. For example: $ id uid=1000(foo) gid=1000(foo) groups=1000(foo) [snip] $ mkdir src $ ls -ld src drwxr-xr-x 45 foo foo 4096 May 10 10:36 src/ $ chgrp devel src $ ls -ld src drwxr-xr-x 45 foo devel 4096 May 10 10:36 src/ $ chmod g+ws src $ ls -ld src drwxrwsr-x 45 foo devel 4096 May 10 10:36 src/ $ cd src $ touch foo.c $ ls -l foo.c -rw-r--r-- 45 foo devel 4096 May 10 10:36 foo.c $ chmod g+w foo.c etc. Again, this headache can be eliminated by setting the umask to '0002' in their .bashrc, .profile, etc, or it could just be set it system-wide, seeing as though we're implementing UPG from the outset. In my professional experience, I've seen cron jobs setup to navigate to a development directory, and 'chmod -R g+w *' to make sure the write bit is set, which is rather pathetic (and inappropriate) if you ask me. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 5/10/2010 11:24 AM, Drake Wilson wrote: > FWIW (which is probably vanishingly little), I find that dealing with > significant group or even inter-user interactions on Unix machines > eventually gets nearly impossible in the absence of full POSIX ACL > support. Modern Debian supports this well with a suitable filesystem > on the backend, though depending on your interop requirements there > may be other problems. I have no problems with FACLs, except they add to added complexity and administration to the filesystem. They're difficult to maintain when multiple groups and users are involved. When scattered about the filesystem, it's not trivial to remove ACL permissions when users or groups are removed from the system. Making the default umask '0002' system-wide on a base install, however, is extremely trivial. Having the administrator then set FACLs as appropriate can be at their discretion without getting in the way. > I regularly set my personal umask to 0077 because I find accidentally > creating files that other users can snoop on to be more dangerous than > having to chmod files after the fact. Conversely, setting default > ACLs is one of the first things I do when setting up collaboration > directories. FACLs on collaborative project directories and files is almost a necessity, and I understand the security of changing your umask to something more tight on multi-user systems. And if the umask switches the other direction to '0077' in the name of security, I don't see any problems there. However, leaving it at '0022' is just historical baggage, and there's no good reason to leave it there. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 5/10/2010 1:07 PM, Klaus Ethgen wrote: > I still makes sense. The user will not win with the lazier umask but he > will probably loose security. > > See the case the user wants another person in his own group to share > files. Then he might set the files readable for his group only but not > for world. So the other user can read this data. But he cannot write it > as it might be intended. > > Setting the umask to 002 let the other user _edit_ all files the user > did create in the past with that umask factual giving away most of his > files. The point of UPG is to not put users you don't trust in your private group. That's why it's called "private". :) If you don't trust users in your UPG, then the administrator should setup a different group, and put the necessary users in that group. > The better Idea would be to set the user mask to 027 which then add a > new value of security. > > If a user want the group to have write permissions this should be set > explicit. By the way, with zsh you can make directory profiles which > set the umask depending on the directory. I'm all for increasing security, but it always comes at a cost. Nothing in security is free. In this case, the convenience of setting up group collaboration directories becomes a pain to administer, as the group write bit is never set, and cron jobs, profile-specific umask values, or FACLs are used instead, adding to the complexity of the system. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 5/10/2010 4:46 PM, Klaus Ethgen wrote: > You can never trust anybody for giving him rights to _all_ of your > files. So this assuming is never true and a user will not have any > benefit of this group if the umask is 002! I trust my wife to all of my files. >> If you don't trust users in your UPG, then the administrator should >> setup a different group, and put the necessary users in that group. > > Give me one case where this is true. If there is a group for sharing > purpose the users will use it -- and will lower there security down to > nothing. Setting a default umask of 002 is highly negligent! We have a 'weblogic' group where many user accounts are added, so they cane manipulate webolgic domains and configurations. Would you like more examples? > Thats true. But setting the umask to 002 will lower them for no benefit. I've told you how making the umask '0002' increases collaboration for development teams. And it doesn't change the security of files that has your UPG as the group of your files/dirs. Everyone not you, or a member of your UPG still falls under the 'other' permissions, so for the sake of security, you might as well change it to '0007'. My argument is about the group permission, not other. > The crazy idea of setting the umask to 002 per default will end in many, > many systems where the users have a low as nothing security for they > important files only to serve some few use cases where the persons > normally know how to get rid of anyway. Explain the security implications of '0002'. Your home directory will be 'drwxrwxr-x foo foo', so anyone who is not user 'foo' or in the UPG 'foo' won't be able to modify a thing. If you're concerned about them viewing the files, then '0007' would give 'drwxrwx--- foo foo'. Setting the write bit on the group doesn't change any security mechanism for the user 'foo' or his UPG 'foo'. If you're concerned about a developer in a collaboration group doing something nasty, then they shouldn't be on the team. Otherwise, remove them from the group, restore from backup, and carry on. It's easy to say "in the name of security", without really thinking about what you're advocating. Updating the umask value to allow the write bit on groups when UPG is setup (as it is by default) just makes sense. Keeping the write bit off the group, means we're too lazy to change old historical baggage. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/11/2010 07:09 PM, Russ Allbery wrote: > Aaron already explained this, but I was confused for quite some time about > the point of UPG and I'm not sure I would have gotten it from his > explanation, so let me say basically the same thing he said in different > words. > > The purpose of UPG is not to use the user private group for any sort of > access control. Rather, the point is to put each user in a group where > they're the only member so that they can safely use a default umask of 002 > without giving someone else write access to all their files. Then, the > right thing will happen when that user edits files in a shared space owned > by some *other* group. Without UPG, you can't safely set a umask of 002, > but when UPG is in place, you should be able to without broadening the > access granted to the user's own files by default. It then makes project > directories with a sticky GID bit *much* more useful. > > UPG without a umask of 002 is pointless. One may as well just put all > users in a users group. Well said. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 5/13/2010 3:34 AM, Philipp Kern wrote: > On 2010-05-13, Charles Plessy wrote: >> If no stronger objections against a change from 022 to 002 is raised, would >> you >> agree changing base-files so that /etc/profile uses 002 on new systems? > > Doesn't that lead to "great fun" if you activate NIS or similar means > to sync unix users and groups on such systems, if they aren't set up to > use UPG too? So that would need a big fat warning in the release notes > and somehow I fear bad PR. :P Can you provide a documented use case for NIS or NIS+? Speculation is one thing, implementing it is another. I'm utilizing OpenLDAP with autofs to mount user home directories on RHEL 5 systems when users login. Everything plays nice, just as you would expect, permission-wise. They have their own UPG, and the default umask is still 0002. Because most of these are developers developing in /u01, it's trivial to setup the collaboration as previously mentioned. I don't have experience with NIS or NIS+, however, so I would be interested in learning any problems with either of these setups. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 5/13/2010 3:48 AM, Santiago Vila wrote: > Will be done in base-files 5.4. I just saw the change committed. Thank you very much! This is good news. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434#25 -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: Open then gates
On 05/14/2010 06:40 PM, Klaus Ethgen wrote: > Oh, I will not make any more comment to that decision. Maybe I will > search for a more secure distribution. This decision is much to much. > And it is the last straw that breaks the camels back. Debian was was my > favorite distribution for over ten years now but in the last time the > concessions to colourful systems where user simplification goes over > security is the wrong way. If you think that changing the default umask to 0002 for user private groups is compromising security, you don't understand the change, nor the system its implemented upon. If you have questions about UPG, or umask, feel free to ask. We'll try to help clear them up. > Christoph did say it with the right words, just start to use Windows as > base for the distribution. Sorry, but this is more and more the picture > I have of Debian. No, Christoph was just spreading FUD, as are you. This isn't about Ubuntu, Windows, Mac or any other operating system. It's about correctly identifying how to increase the functionality of the operating system. Again, if you truly understood the change... > Oh, there was technical arguments in the thread. But they was just > ignored. But there was just one reason to make the umask that more > insecure, and this is a very special usecase. Compared to the technical > arguments against the change this has nearly no weight. (I was myself in > the situation that I had to setup a directory for collaboration work. > But this didn't need to set the umask of all members to a insecure > umask.) You need to explain clearly how the umask of 0002 is insecure. If you have members in your user private group, then your group isn't private, is it? UPG is designed to NOT have anyone else in your group except you. So, adding the write bit on the group mode does not affect security in the least. > If they destroy a distribution, yes! No one is destroying anything. It's rather unfortunate that you don't understand the argument you're making. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: Bug#581729: [SQUEEZE] Document the umask change for new installs
On 05/15/2010 05:26 AM, Christoph Anton Mitterer wrote: > On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote: >> for regular users > Would have to double check it,... but doesn't the current change also > affect root? This does, but root is also in his own UPG. If you add any user to the root group (same this as using wheel on other systems), you're effectively giving that user full root access to the system anyway. So, this change will not have any unsavory side effects for the root user or group. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: Bug#581729: [SQUEEZE] Document the umask change for new installs
On 05/15/2010 05:50 AM, Christoph Anton Mitterer wrote: > On Sat, 2010-05-15 at 13:45 +0200, Holger Levsen wrote: >> This paragraph should be accompanied by something like: >> >> Instead of adding users to other users private groups (which has issues as >> explained above) it is recommend to create dedicated groups for these users >> for collaboration. > Perhaps I'm completely stupid,... but why do we have UPGs then at all? User private groups are NOT intended to add other users too. That's why it's called "private". The motivation behind creating a UPG setup was to have more flexible group collaboration, without sacrificing security on the system, or changing how standard UNIX permissions work. This has been discussed already. > For those rare cases like "a user's wife/husband" which is fully > trusted? Personally, I trust my wife, and have no problem adding her to my own private group. However, it still is better to create a different group, add both myself and her too, and use that to share the files. There may be a time, when I am shopping online, or working on something I don't want my wife to see, so putting her in my private group might have been a mistake. Even if I fully trust how she'll handle those files. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: Open then gates
On 05/15/2010 02:00 AM, Robert Klotzner wrote: > Also as far as I understood from a previous post, this change will only > affect > new installations, not existing ones. So even if a user misunderstood the > concept and added other users to his private group, this change does not > affect > him. If the change is documented in the release notes and in the > installation > manual of squeeze, I do not see any problems. Of course you can assume that > the user does not read them and just does stupid things, but this is an > entirely different issue, you can never secure a system against mindless > administrators, no way. There are no security problems with this change, and you understand correctly- this will only be implemented on new installs. If the administrator is adding users to private groups, the it's the fault of the administrator making bad choices on the system, not the fault of Debian. > So I see your argument about not to be thought of side effects, but the > concept > as such is proved already and the only harm could arise from systems where > users assume the old umask still to be in effect when they update to squeeze > and it will, so what is the problem? There isn't a problem. The ones starting this thread are reaching for straws trying to create a problem. Sure, we'll have some apps such as Mutt or SSH that might hiccup, and stuff like this is expected. Anytime a change is made on the system, bugs will arise. But fixing those bugs makes the system better than before the change was implemented. This is a net positive win for Debian, its administrators and all those who use it. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: Bug#581729: [SQUEEZE] Document the umask change for new installs
On 05/15/2010 10:47 AM, Santiago Vila wrote: > On Sun, 16 May 2010, Charles Plessy wrote: > >> Also, I have not seen on -devel that the idea of having a different >> umask for system and regular users has been implemented in >> base-files yet. I propose to not mention this until base-files is >> updated to support it. > > The file /etc/profile is only read for login shells, or shells that > pretend to be login shells. > > Do we really have to make /etc/profile more complex to deal with > system users who login to the system? > > Are there any? (other than root, who already has its Private Group). > > Is it ok at all that a system user does a login to the system? The root account is the only account that is a system user/group that is a private group. The rest should not have login shells, that I understand, so setting the umask system-wide shouldn't be a problem. However, we do have the "staff" group, which is a system group and the "users" group at GID 100. Both of these, I'm assuming come from historical UNIX? Should their umask be 0022? Or do they have a different purpose? Just making sure all of our bases are covered with this change. I think we all want as little surprises as possible. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/15/2010 02:51 PM, Willi Mann wrote: > Is it possible to detect whether an account is configured properly based on > the UPG idea? If yes, wouldn't it then make sense to only set umask 002 if a > proper UPG account is detected, otherwise 022? This would avoid putting non- > UPG systems on danger. I proposed this change to the /etc/profile file [1]. This logic seems "good enough" to determine UPG accounts. Further discussion however shows that other than root, system users don't have login shells, and as such, won't process the /etc/profile file. Also, because root has its own UPG, there's really no need for the logic. My only question is then, why is their default shell /bin/sh, and not /bin/false or /usr/sbin/nologin if they indeed are not login shells? The "staff" and "users" groups might be problematic, if system administrators are using those groups similar to how Solaris or HPUX are using them (respectfully). However, I would venture that if the administrator has his system setup that way, he's aware of the necessary umask needed for that setup. If there are systems setup in this manner, we'll likely see bug reports about it. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434#70 -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/15/2010 12:16 AM, Vincent Danjean wrote: > Somethink is wrong here. Should 314347 be reopened ? Agreed. It's not working as it should. Running openssh-client version 1:5.5p1-3, and setting the write bit on my private group seems to keep the client from behaving as expected. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/16/2010 12:39 PM, Russ Allbery wrote: > Because the further discussion was wrong. System users have login shells > in Debian. (I consider this a very long-standing bug.) Then the logic should be in play. System users don't necessarily have a private group, so their umask should be 0022. If they are not intended to be login accounts, then their default shell should be changed to /usr/sbin/nologin or /bin/false. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/16/2010 05:11 PM, Santiago Vila wrote: > They have login shells in the sense that their shell field in /etc/passwd > is /bin/sh, but if they do not really "login" to the system, then they > do not read /etc/profile. > > In either case, if we plan to set default umask in /etc/login.defs or > using PAM, I will happily drop the umask setting from /etc/profile, > as we don't need to have the required "logic" by duplicate. Curious, if umask isn't specified explicitly, what is it? For UID 1-99, what we're discussing here, what would happen for their umask value? Will it be 0022? ? Something else? Also, if the system users aren't processing a login shell, then why isn't their default login shell /usr/bin/nologin or /bin/false? Should a wishlist bug be submitted against this? -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/17/2010 07:00 AM, Mike Hommey wrote: > There is no such thing as Debian's idea of UPG. There is simply the fact > that when you create a user with UPG, it uses the first uid and the > first gid available. It can happen that they don't match, in the > scenario I gave above. This applies to any distro, afaik. Yes, this is trivial. Create a group first, before creating a user, and after creating users from there on, the UID and GID will be one off. This is natural, and nothing to worry about. Unless you're obsessive compulsive about the ids matching. :) -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 5/17/2010 7:34 AM, Marvin Renich wrote: > This looks like a bug in pam_umask. UPG has never guaranteed uid=gid. > I'll file a bug. While the numerical ID might not match, the names should: id -gn should equal id -un After all, that is part of the definition of the UPG setup. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/17/2010 10:02 AM, Harald Braumann wrote: > - you could have a UPG system but a mismatch of IDs -> wrong umask ID numbers, yes. ID names, no. If the user name maches the group name, IE: aaron = aaron, then the user matches the private group. If the match is not made, then umask 0022 should be in play. > - you could have a non-UPG system but a user's name and ID happen to > match those of the group -> wrong umask If the username matches the group name, then you have a UPG system. Unless you created a user called "devel" and put him in the "devel" group. Debian is not substitute for stupidity. > - you could add more layers and check, e.g., if the user is the only > member in the group. but more users could be added later making the > first user's files writeable by those. > > No matter how much clever logic you put in there, there is simply no > way to make this work reliably because it's based on wrong assumption. There is no complex, additional layers to check. You only need to match the user and group names. If they match, it's UPG. If they don't, it isn't. Give me a realistic case where this would be problematic. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/17/2010 10:49 AM, Harald Braumann wrote: > On Mon, May 17, 2010 at 10:14:28AM -0600, Aaron Toponce wrote: >> On 05/17/2010 10:02 AM, Harald Braumann wrote: >>> - you could have a UPG system but a mismatch of IDs -> wrong umask >> >> ID numbers, yes. ID names, no. If the user name maches the group name, >> IE: aaron = aaron, then the user matches the private group. If the match >> is not made, then umask 0022 should be in play. > > from pam_umask's description of the usergroups option: > > If the user is not root, and the user ID is equal to the group ID, *and* > the username is the same as primary group name, the umask group bits > are set to be the same as owner bits (examples: 022 -> 002, 077 -> > 007). > > So if there is a mismatch of *either*, name or ID, then pam_umasks > detects a non-UPG system, while it might very well be all UPG. A bug in pam_umask.so that needs to be addressed (which I believe we've already started addressing in this thread). > Also, > just because Debian's adduser happens to give the same name to the > user as well as to his private group, this is not necessarily true in > all system. You could have group names that are prefixed with "grp", > or whatever, but still have a perfectly valid UPG system. Can you produce a valid example? The definition of UPG is to create a group name that is the same as the username. If the system in question is using UPG, then there won't be any conflicts, unless the admiinstrator tries creating a "adm" user, or something equally as unsound. >> If the username matches the group name, then you have a UPG system. > > And on what assumptions do you base this conclusion? This is how UPG works. A new user is added to the system, and a group of the same name is also added to the system. This is fundamental to UPG. >> Unless you created a user called "devel" and put him in the "devel" >> group. Debian is not substitute for stupidity. > > How is that stupid? Users and groups are completely seperate name > spaces, so why would I care in a non-UPG system? If you're using a non-UPG system, then you don't care. Debian is UPG-based, so your argument is invalid. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/17/2010 11:10 AM, Christoph Anton Mitterer wrote: > As far as I understood,... you guys are already starting to patch > unrelated software just to make UPG work (see > #581919). > > Even the title of that "bug", "bad ownership or modes..." is > ridiculous... and proves what I've predicted before, namely that these > changes will compromise security (such a patch will also affect non UPG > systems). You haven't shown any implementation that security will be compromised in any way. You just keep throwing it around, which isn't doing anything for the discussion. > On Mon, 2010-05-17 at 11:04 -0600, Aaron Toponce wrote: >> If you're using a non-UPG system, then you don't care. Debian is >> UPG-based, so your argument is invalid. > You actually, have to care... at least if #581919 is "solved". 581919 is a regression from 314347. It should be fixed just on that basis. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/17/2010 11:46 AM, Christoph Anton Mitterer wrote: > If you need to change for example ssh, to allow an authorized_keys file > or perhaps even things like ~/.ssh/id_rsa to be group-readable and/or > writable you actively compromise security, at least for those systems > which do not use (for whatever reason) UPG. How does this compromise security when you're the only member of your private group? > I guess upstream haven't added that permissions checks just because life > was so boring, but rather for some specific reason. > In the case of authorized_keys, I assume, to prevent "social > attacks" if you know which people are allowed to access a machine, > it's much easier to get their keys... Setting any permission bit on any file on any computer won't protect you from social engineering, so I fail to see where you're going with your argument. > Or do I understand the idea behind 581919 wrongly? 581919 was created, because the write bit should be set on the ~/.ssh/ directory, and contents, seeing as though Debian is a UPG-based operating system. The only user of the private group is the owner of the file itself. This was the reason for 314347, as SVN was behaving unexpectedly. Thus, a regression. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/19/2010 11:25 AM, Santiago Vila wrote: > For the record: I've changed the umask setting in /etc/profile to this: > > if [ "`id -u`" -ge 1000 ]; then > umask 002 > else > umask 022 > fi [snip] > Some people proposed complex code to determine whether UPG was in use > for system users. Such thing would be an "exception to the exception" > and as such I think it would be a bad thing, as it would make things > a lot more complex without any real gain. I suggested this, which I don't think is complex. However, what you have suggested should work just fine. if [ "$(id -un)" = "$(id -gn)" ] && [ "$UID" -gt 99 ]; then umask 0002 else umask 0022 fi The logic is simple, IMO: if the group name and the user name match, it's UPG. If UPG and it is not a system user, then set the umask to 0002. Otherwise, set to 0022. I don't know if that logic will match any additional cases (unless user accounts are created under ID 1000), however, so we should be good with your simpler logic on just matching the UID. Speaking of which, because of NFS, should matching just the UID -ge 1000 a good idea? Other systems start their accounts at 500, and matching UID is critical in NFS environments. Just a thought. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/19/2010 01:00 PM, Philipp Kern wrote: > When I do "newgrp " it's still UPG and the umask should still be > 2, no? This check would change my umask. If the new default group is named something other than your username, it's no longe UPG. UPG is only if the user name and group name match, and the user is the only member of that group. So, to answer your question, if your username was "foo" and you belonged to group "foo", of which you are the only member, then you do a "newgrp bar" for foo, foo is no longer in a UPG situation, so his umask should be 0022 at that point. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/19/2010 01:20 PM, Philipp Kern wrote: > Sorry, I assumed that UPG is a system-wide concept and that I could just > change to my collaboration group and have a useful umask there too. So we > only cater for the setgid flag on directories? The "newgrp" command changes your default group. The default group is what is applied to files when you create them. So, if you change your default group to a collaborative group, then realize that they will have access to those files you create outside of the collaboration directory. The better way to approach this, would be to just append the collaborative group to the user, but keep his private group as his default group. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/19/2010 01:25 PM, James Vega wrote: > Except /etc/profile won't be sourced again unless "newgrp - " is > used, right? Correct, or the user issues a new login shell after the change has been made. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/19/2010 03:11 PM, Christoph Anton Mitterer wrote: > Or is that already, the case? At least I've had the impression that > neither mine, nor the arguments of some other people (Harald, Peter, etc.) > were even answered here. You've only mentioned that SSH won't operate if the write bit is set on the keys or anything under the ~/.ssh/ directory. Can you explain how an ssh client failing to connect to an external ssh server because of the umask is compromising security on the system? Also, can you please provide an extra carriage return between your reply and the quoted text? Reading your replies is a bit annoying. > The reason could be that people simply don't recognise, that they might > have compromised their own security... and those who know what happens > don't complain. Please explain how people's security is compromised because their umask is 0002 instead of 0022. I'm still waiting for this FUD to be backed up. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: UPG and the default umask
On 05/19/2010 03:48 PM, Christoph Anton Mitterer wrote: > See above, or do you wish a larger paper discussing the issues?! ^^ So FUD it is. At least you're consistent. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: Bug#581488: general: lower vm.swappiness by default for desktop installations
On 5/12/2010 1:22 PM, Marcus Better wrote: > Recently I got the advice [1] to set vm.swappiness to 0, rather than > the default 60. This improved things dramatically. Apparently Eclipse > is no longer being swapped out preemptively all the time. The > difference in perceived responsiveness is spectacular. You might also be interested in: # sync; cat 3 > /proc/sys/vm/drop_caches This is a nondestructive operation that will drop your clean caches, clear up unused inodes, and free up available RAM. Usually, after running my desktop for a few hours, depending on the applications I'm running as well, this will free up about 1/2 of my installed RAM. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
xulrunner 1.9.2 into sid?
Seeing as though upstream Firefox 3.6 released December 1, 2008, and upstream Thunderbird 3.1 released just a couple days ago, it might be high time to get xulrunner 1.9.2 into Sid, as both Iceweasel 3.6 and Icedove 3.1 will depend on it. However, I hear there will be lots of breakage if xulrunner 1.9.2 comes into Sid. If so, what will break? Further, what can I do to help? -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: xulrunner 1.9.2 into sid?
On 06/28/2010 02:34 AM, Mike Hommey wrote: > The latter also applies for iceape and icedove, and is why 3.5/1.9.1 is > still considered as the release target: iceape 2.0, icedove 3.0, and > iceweasel 3.5 are all based on xulrunner/gecko 1.9.1. Security support > for stable will be easier if there is only one branch to support for the > whole gecko ecosystem. Sure, upstream support for it will be dropped > soon, but we can't expect 3.6 to be supported the whole squeeze lifetime > either. Ah yes, Iceape. Their releases are so few and far between, this could possibly mean that we won't see Iceweasel 3.6 or Icedove 3.1 for some time, correct? Upstream Seamonkey 2.1 will be build against gecko 1.9.3, but its release date is TBD. Upstream Firefox 4 is due the end of the year, based on 1.9.3, and will likely be ahead of Seamonkey. So where does that put us? Seems trying to keep the two projects aligned is some task. :) Will Iceweasel 4 go into Sid when Iceape 2.1 goes into Sid? > First, TB 3.1 has just been released, and as such hasn't been widely > tested in Debian. It usually isn't very wise, that close to the expected > freeze time, to upload a new major release of a not exactly small and > trivial software. I can understand this, but I would imagine the release of Squeeze is at least 8-10 months out. We still have a good deal of RC bugs to get through. Of course, packages this size will add to the count. > Second, for the reasons given earlier, releasing with iceweasel 3.6 and > icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not > be a huge problem, as we already didn't release lenny with iceape, but > see below. Iceape is a beautiful piece of software, and I have run it in the past. But market share shows that Seamonkey/Iceape users are the minority, with Firefox/Iceweasel and Thunderbird/Icedove the vast majority. Releasing Lenny without Iceape was the best move, IMO. > All in all, I still think releasing squeeze with iceape 2.0, iceweasel > 3.5 and icedove 3.0 is the best course of action. Is this really the best move? With Firefox 4 due the end of the year, and 3.6 will be a year old already, the security team will be supporting 3.5 after Mozilla stops it's support. Same might be the case with Icedove 3.0. I can see this is a delicate dance, and I can see the problem of two xulrunner releases in a single archive. I wasn't aware of the technical complexities, so it was good to learn. Thanks for taking the time. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: xulrunner 1.9.2 into sid?
On 06/29/2010 03:57 AM, Adam Borowski wrote: > [1]. A Chromium extension named "AdBlock" exists, but it merely hides the > junk after downloading them -- so you merely don't see them while still > being subjected to slowdown, having your bandwidth stolen, being tracked, > having advertising scripts running, being exposed to more of potentially > unpatched vulnerabilities, and all that kind of goodies... No longer the case with Adblock 2.0, as already pointed out by Evgeni. > [2]. Chromium doesn't even understand the concept of session cookies. It > does allow purging cookies at exit -- but that applies to all cookies, > including the few you do want to keep. Iceweasel's default handling isn't > perfect, but it can be set to something sane even without installing any > extensions, While true, this is rather trivial to setup: rm ~/.config/chromium/Default/Cookies ln -s /dev/null ~/.config/chromium/Default/Cookies -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: xulrunner 1.9.2 into sid?
On 06/29/2010 05:16 AM, Adam Borowski wrote: > Uhm, and that gets me what? It would nuke all cookies, including those > which are supposed to last beyond the session. Touche. I misread your post, and Chromium's ability to do this by default. Apologies. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
chromium-browser in Debian Sid
I just noticed that the chromium-browser package releases in Debian GNU/Linux unstable are synced version-for-version with the google-chrome beta package provided by the 3rd party Google Linux repository. Is this intentional? What's the rationale behind using the beta releases for chromium-browser in Debian rather than just using the nightlies? Just curious. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: chromium-browser in Debian Sid
On 06/30/2010 01:18 AM, Giuseppe Iuculano wrote: > On 06/30/2010 06:15 AM, Aaron Toponce wrote: >> I just noticed that the chromium-browser package releases in Debian >> GNU/Linux unstable are synced version-for-version with the google-chrome >> beta package provided by the 3rd party Google Linux repository. Is this >> intentional? > > No, we follow the stable channel. Stable: 5.0.375.86 Beta: 5.0.375.86 Dev: 6.0.437.3 For some reason, I thought the stable channel was still in v4. >> What's the rationale behind using the beta releases for >> chromium-browser in Debian rather than just using the nightlies? > > Should we use the Chromium nightly builds ? Really? :) Well, when you put it that way. :) Honestly, I don't think of Sid as a collection of stable packages. That's what I think about Lenny. I think of Sid as "the latest and greatest", regardless of version, and that's why I thought the nightlies would be appropriate here. In my mind's eye, I played out that Sid would get the nightlies and Squeeze would get the beta pushes. But, following the stable channel makes sense. I was just curious. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Good News: The Sun RPC license has been changed
You can see the details outlined in this blog post by Tom Callaway: http://spot.livejournal.com/315383.html Long story short: The Sun RPC license that affects this bug has been re-licensed to the 3-clause BSD license. Even though Debian is moving to eglibc, this is still good news. Finally time to close the bug? -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Bug 181493 should now be closed
The Sun RPC license that has plaqued this bug, has been re-licensed to the 3-clause BSD license. This affects glibc and krb5-*, and possibly other packages. The change from Sun is documented here: http://blogs.sun.com/webmink/entry/old_code_and_old_licenses Tom Callaway of Red Hat blogged about the change here: http://spot.livejournal.com/315383.html -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Hashcash token does not represent bits calculated [Bug]
Package: hashcash Version: 1.21-1 According to the documentation, the hashcash binary supports the '-b bits' switch and argument for calculating a hashcash token of the size specified. The default size is 20 bits. The '-b' switch argument supports an exact size, say '-b 40' for minting a 40 bit token, or incrementing/decrementing the size from default, such as '-b +10' to create an additional 10 bits from default (20). This should create a token of 30 bits in size. Same holds for decrementing. Consider the following example: $ hashcash -m foo -Z 2 hashcash token: 1:20:110321:foo::oMOAOyoyMfeKOPg7:5z7t As per the 2nd column of the token, the default of 20 bits was used. Let's increase to 30 bits: $ hashcash -m foo -b 30 -Z 2 hashcash token: 1:20:110321:foo::DPuJxVpBd5hjE+WX:7CR2 The 2nd colomn shows that only 20 bits were calculated, versus the 30 that I requested. This can be verified with SHA1 showing that the first 20 bits are zero, not the first 30: $ echo -n 1:20:110321:foo::DPuJxVpBd5hjE+WX:7CR2 | sha1sum 0239da10b8f4cf3aadd15d62b2d0c261dc82 - The same bug exists for incrementing and decrementing the bit size. The 2nd column should convey the bit size that I requested with '-b bits' and verifying with SHA1 should show the firt few bits as zero, as specified. Compare with a 44 bit token found at http://hashcash.org/stamps/: $ echo -n 1:44:070217:foo::xSi0bPjoswUh6h1Y:TMNI7 | sha1sum 0005ae959bd508c19ba300b1088410aa - This is a Debian GNU/Linux unstable operating system running with: 2.6.37-1-686 #1 SMP Tue Feb 15 18:21:50 UTC 2011 i686 GNU/Linux With C library version: Version: 2.11.2-11 -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o signature.asc Description: Digital signature
Starting services automatically after install
I'm trying to dig through the archives to see if this has been discussed,
and I'm only finding random one-off discussions here and there about it.
Nothing concrete. If it has already been discussed in great detail, my
apologies.
By default in Debian, when a service package is installed, such as
openssh-server, or isc-dhcp-server, it starts the service. This seems
counter-intuitive to me. I would think that the standard mode of practice
for installing and running a service would be as follows:
1. Install package
2. Configure service
3. Start service
Instead, I find myself doing a lot of:
1. Install package
2. Stop service
3. Configure service
4. Start service
I only bring this up, because I recently booted into a Debian Live 6.0.4
image, and found 32 (thirty-two!) services listening on external
interfaces, including port 6667! Further, ISC DHCP tried starting, although
it failed. Why is a DHCP server trying to start on a rescue tool?! Why is a
rescue tool running any services at all?! Especially ones listening on
external interfaces!
Anyay, that's off-topic. Just because I have installed a service package,
doesn't mean I want the service immediately running after installation. I
would like to spend the necessary time as an administrator to configure and
secure the service to my liking, before starting the service.
I would be interested in the opinions of the rest of the development
community on this, and why Debian handles services the way it does
currently. For comparison, Fedora and Red Hat Enterprise Linux do not start
a service after install. {Free,Open,Net}BSD start some, but never on
external interfaces. AFAIK, Arch Linux does not any services by default
after installation. . It seems that only Debian-based operating systems do.
Thanks,
--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o
--
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/20120601172242.ge12...@kratos.cocyt.us
Re: Starting services automatically after install
On Fri, Jun 01, 2012 at 07:49:03PM +0100, Philip Hands wrote: > The reason that RedHat don't start things is that their default approach > has been to install a whole load of stuff that you might possibly want, > and allow you to enable it when you are inspired to give some new > service a try. > > The Debian approach has always been to not install anything that you > don't intend to use. It is also to ensure that if you do choose to > install something, it should be doing something useful by the end of the > install (if possible, security considerations allowing). I don't understand what you are saying. When I install a RHEL system from scratch, as with the Debian Installer, it's trivial to install just a base system, then install the software you need after that. In this case, I will do a "yum install httpd", and it will install Apache and its dependencies. In a similar fashion, doing an "aptitude install apache2" will also install Apache and its dependencies. Both systems will be in a similar state with installed software, except RHEL will wait for me to configure the package first, before starting, while Debian is shiiping the "It Works!" page to anyone who queries the server. > That is also why Debian and RedHat diverge when it comes to prompting > the user for configuration questions -- RedHat just want the software to > install, whereas Debian wants it to be useful, so may need to ask > questions. I also don't understand what you are saying here. Red Hat installs the software and makes it possible for me to start providing value to my "customers", as does Debian. What do you mean that Red Hat does not want useful services, and Debian does. > It also leads to the fact that you can do major release upgrades of > Debian, whereas that's not really supported in RedHat, as chances are > your configuration is going to get trashed to some extent, and they > don't have the chance to ask you what you want to do about it. No. In both cases, doing a major release, whether Debian stable -> Debian stable, or RHEL 5 -> RHEL 6, there is going to be breakage. This should always be heavily tested before such a massive migration. This is why there is such things as "development" and "QA" evironments. You always test major software upgrades before doing them. Regardless of operating system. Heh. > If you don't like the assumptions, you are much better off switching to > a distribution that you prefer, rather than trying to persuade the > overwhelming majority of the people that like the current assumptions, > and use Debian because of those assumptions, that they should change > their minds because they are supposedly wrong for liking it that way. Wrong answer. Rather than telling people to go elsewhere, because you don't understand their point of view, the constructive approach would be a discussion about adding a /etc/default/services config file, with "START=on" or "START=off", or something similar. Debian provides a great deal of value to me and many others. Just because it might have one point that I don't agree with, does mean I should ignore all the other points that I do agree with, and use a different operating system. I'm curious how this solves any problems at all. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o signature.asc Description: Digital signature
Re: Starting services automatically after install
On Fri, Jun 01, 2012 at 08:23:20PM +0200, Jonas Smedegaard wrote: > Debian goal is - as you probably know already - for packages to work out > of the box. For daemons this means they are started by default. > > If a package (service or not) is insecure by default, it is a bug! > Severity of such bugs vary - e.g. some may consider it insecure for a > web server to publicly display a static page saying "It works!" while > most probably won't. > > You can override the default of daemons using policy.d. > > What I do for chroots - which you can adapt to your own personal needs, > is to install the package policyrcd-script-zg2 and add the attached > config file as /usr/local/sbin/policy-rc.d . (Snipped code) This is quite a bit of work from the administrator's point of view. And, as much as we would not like to admit it, no software is "secure by default". Security isn't a binary function. I wouldn't mind so bad if the services listened to localhost by default, and not on external interfaces. This would allow me to make configuration changes, and continue to reload the service, testing locally, until I'm satisfied it can be for the general public, or whomever my customers are. Enabling services on external interfaces by default is indeed a bug, IMO, especially things like SSH, DHCP, SMTP or Bind (which has a long history of security problems). -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -- 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/20120602142101.gg12...@kratos.cocyt.us
Re: Starting services automatically after install
On Sat, Jun 02, 2012 at 04:02:57PM +0300, Serge wrote: > I'm not experienced in this topic much yet, that's why I'm writing not in > list, but directly. Feel free to reply into list, if you wish. I would prefer to keep it on the list for a public archive, and to benefit the greater admin population. > I understand both approaches, so here's the question/suggestion. > > If both approaches are valid and there're people who likes each of them, > then, maybe, we can suit them all. > > Is it possible to configure dpkg (or something else) so that it would not > start services? I.e. is there some simple option, like: > echo START_ON_INSTALL=no >> /etc/dpkg/dpkg.cfg > so that one could configure which approach he likes? This, or a global /etc/default/services (or similar file) for all services. However, I am calling into question the validity of starting a service by default post-install. I think it introduces security concerns, possible headaces on the local LAN, and just unnessary work for the administrator. Other than "if you don't want a service, don't install the package" agrument, I don't understand why services _should_ be started by default post-install. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -- 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/20120602142539.gh12...@kratos.cocyt.us
Re: Starting services automatically after install
On Sat, Jun 02, 2012 at 10:43:00PM +0200, Tollef Fog Heen wrote: > Are you seriously suggesting that DHCP and SSH servers should not listen > on external interfaces by default? The use case for SSH or DHCPd on > localhost only is pretty small. I would much rather have DHCP listening on localhost, than competing with an already existing DHCP server on the LAN. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -- 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/20120603032337.gi12...@kratos.cocyt.us
Re: Starting services automatically after install
On Sun, Jun 03, 2012 at 02:46:21PM +0800, Chow Loong Jin wrote: > Is there even a point in having DHCP listening on localhost? So, why even bother starting it? Thus, the whole point of this thread. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgpNM5x5kxGQE.pgp Description: PGP signature
Btrfs limitations in the Debian installer 7.0 beta4 release
Recently, I decided to put down a Btrfs root on my workstation using the latest release of the installer. I found that given my hardware configuration, this is not possible, and would require using another installer or debootstrap the installation, which is far from ideal. I have two 250 GB drives I would like to put into a RAID-1 mirror. I want Btrfs to handle the RAID, rather than mdadm. It appears that this is not possible in the installer, as when you are at the partitioning screen, it forces you to decide which partition gets mounted to root. Instead, I'll pull up tty2, and manually build the array. Suppose they are identified as /dev/sda and /dev/sdb. I would like to partition the drives, such that /dev/sda1 and /dev/sdb1 make up the root Btrfs filesystem, and /dev/sda2 and /dev/sdb2 make up a ZFS /home. After partitioning the devices, I run the following command to create the Btrfs RAID: # mkfs.btrfs -d raid1 -m raid1 /dev/sda1 /dev/sdb1 # mount /dev/sda1 /target/ Now, I would prefer to have the root into a subvolume. So, I run the following command: # cd /target/ # btrfs subvolume create root # cd # umount /target/ # mount -t btrfs -o defaults,subvol=root /dev/sda1 /target/ Recognize that I am effectively mounting /dev/sda1/root (if such a device actually existed) to /target/, and not /dev/sda1. However, the partitioning utility will not allow me to modify the mount options when specifying which subvolume should be mounted to /. So, if I specify /dev/sda1 to be /, the debian installer will "umount /target/" and "mount /dev/sda1 /target/" which is not what I want. Further, asside from pulling up a terminal in the installer, there is now way in the partitioning utility to setup Btrfs volumes using multiple devices. You must set that up in tty2 or tty3. (As a tangent gripe, the partitioner will also not allow you to setup an encrypted partition. You must do encrypted volumes with LVM. You can defeat this by again going to a TTY.) Doing a GRUB install on both /dev/sda and /dev/sdb is not a problem, and I can configure GRUB to assemble the Btrfs volume, and I can make the necessary changes to notify the kernel where the root filesystem is. However, all of these require stepping out of the Debian installer, and using another vendor's install, such as Ubuntu or Fedora, to bootstrap it. Again, far from ideal. It would be nice if the partitioning utility allowed the administrator to specify mount options (asside from checkboxes with 'noatime', 'relatime', etc). This way, I could tell the installer to mount the subvolume as root, and not the partition. I can file a feature request, if needed. Thanks, -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgpyjf33vw0Z0.pgp Description: PGP signature
