Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues
Am Thu, 01 Jul 2010 09:31:47 +0200 schrieb Goswin von Brederlow : > The bigger problem is later during boot when you need to wait for all > devices to appear so /usr, /home, ... can be mounted. One way to solve > this would be to have the fsck and mounting of filesystems wait for > the specified timeout for the device to appear as well. So even more > event based stuff. Event based init systems need some watchdog type behaviour in any case, like "mountall" with upstart/ubuntu. > Another issue is that in the case some device is missing and you do > run into a timeout things have to timeout in the right order. > E.g. /dev/md1 waits for /dev/sdc1 and lvm waits for /dev/md1. > Then /dev/md1 has to timeout first and come up degraded so the lvm > starts successfully. And I think at that point the only solution is > to know the layering of devices so the layers can timeout lowest to > highest. There are some notes at: http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices/How-To-Boot The init watchdog needs a list (or tree of dependencies) of devices/events to wait for, degrade or fail. Cheers, Christian -- 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/20100705092404.460b6...@smtp.tu-bs.de
maintainer rejected completing the UPG checks (was: test if primary group, with only implicit membership of the user?)
My perception was that the consensus reached was that we wanted umask relaxation to be safe. Bug#583970: pam_umask "usergroups": test if primary group, with only implicit membership of the user Closed on Sun, 6 Jun 2010 15:32:43 -0700: > I don't think this is a check that it makes sense to add to > pam_umask. This isn't part of the *definition* of user-private > groups, it's just a feature of the most common *implementation* of > UPG. IMHO the same holds true for the username and user-ID checks in place, they are not strictly required for an UPG implementation. If the group can be considered to be a private group (and be granted write permissions) is ultimately only determinable by the user looking at and knowing/trusting the members of his primary group. What distros do is, they add certain properties to UPGs to be able to recognize the UPGs that are set up by their tools. Completing the set of checks to match the set of properties of distro's UPG implementation increases the security of the common implementation of UPGs. It eliminats the cases of insecure umask relaxation! Because the set of checks is incomplete (does not cover the specific properties added) I'd even consider it a security relevant bug, not only a wishlist item. Even if the check would not be enabled by default upstream, Debian could (and according articulated security concerns, Debian probably should) enable it, because Debian's UPG implementation supports those UPG properties. (Well, at least the one that is checked with the above test. The UID==GID alignment will be fixed.) Cheers, Christian -- 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/20100610134950.709a9...@smtp.tu-bs.de
Re: finally: packages to optionally create default collaboration dirs
Am Fri, 4 Jun 2010 12:21:56 +0400 schrieb Stanislav Maslovski: > Well, and how does _your_ proposal implement _full_ choice? IMHO we are at a place to suggest constructive answers and enhancements to proposals. Everybody lives happily with things they don't need nor are affected by. Regards, Christian -- 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/20100604123844.0558b...@smtp.tu-bs.de
Re: cryptdisks(-early) initscripts, dependencies and loops
Am Fri, 4 Jun 2010 02:49:32 +0200 schrieb Petter Reinholdtsen : > It is possible event baset boot sequencing might make it easier to > change the ordering, but also there the maintainer of a package need > to decide on some ordering. The defined order in /etc/init/cryptdisks-udev.conf is simply "start on block-device-added ID_FS_USAGE=crypto". The boot sequence then automatically corresponds to how things have been installed on top of each other. You'd have to check if upstart is ready for use in initramfs. Cheers, Christian -- 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/20100604105516.1fd62...@smtp.tu-bs.de
Re: finally: packages to optionally create default collaboration dirs
Am Thu, 3 Jun 2010 00:43:20 +0400 schrieb Stanislav Maslovski : > > The great thing about Debian is that it can mean and handle so many > > different things for so many people. > > Yes, that is why we should not limit it to a fixed number of > predefined choices. Configurable defaults should implement full choice, unlike missing functionality. One can miss some configuration options about the optional setup of collaboration directories (think $HOMEs for groups), but sorry, Debian's mirriads of functionalities or packages that one can perfectly keep disabled (or not installed) can hardly be unacceptable. Cheers, Christian -- 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/20100603103609.0a8e5b40c.gatzeme...@tu-bs.de@tu-bs.de
Re: cryptdisks(-early) initscripts, dependencies and loops
Am Tue, 1 Jun 2010 22:08:19 +0200 schrieb Jonas Meurer: > should i > simply tag the bugs as wontfix, describing that a solution is > impossible? Some of the setups you describe may work event based using the current upstart init. Cheers, Christian -- 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/20100602123316.4942d3e6c.gatzeme...@tu-bs.de@tu-bs.de
Re: finally: packages to optionally create default collaboration dirs
Am Wed, 2 Jun 2010 12:53:03 +0400 schrieb Stanislav Maslovski: > But why Debian should care about the precise details of local > admistration policies? If you have read #248130 and know debian, you probably know local details are usually nicely configurable. You probably also know about debconf, preseeding and priorities anyway. I.e. for addgroup a configuration analogy to adduser's homedirs would be: GROUPDIRS=no DGROUPDIR=/home/group QUOTAGROUP= GROUP_DIR_MODE=2775 > what is required from a distribution is > just a set of sane defaults. Before we can actually choose any defaults, we need functionality that is able to optionally set up collaboration directories. To set up the directories that are bound to groups, addgroup is the obvious place for this. I don't know the right place yet though, for the option to set up the groupdir for the "users" system group, and ~/private and ~/incoming for each user. > in reality such > unnessesary options will only confuse inexperieced users and irritate > administrators. Ready to go and easy collaboration among the users of a system may not be necessary and welcomed by everyone. Just stay with those things disabled then, you shouldn't even notice. I'd like quote Petter here, "You should not really allow your lack of imagination to limit what computer systems can handle. :)" The great thing about Debian is that it can mean and handle so many different things for so many people. Thank you for being helpful to flash this out. Cheers, Christian -- 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/20100602115918.3a0f386ec.gatzeme...@tu-bs.de@tu-bs.de
Re: finally: packages to optionally create default collaboration dirs
Am Wed, 2 Jun 2010 01:20:00 +0400 schrieb Stanislav Maslovski : > > But where/how should those things be created best? > > Should not be created at all on default installs, thanks. Do not worry. They are not to be created by default. If you read the subject it even explicitly reads "optionally create". > Those things should be under control > of a local administrator. And the functionality should be handled by a configurable option in Debian. -- 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/20100602102735.60df7720c.gatzeme...@tu-bs.de@tu-bs.de
finally: packages to optionally create default collaboration dirs
If collaboration among users should work nicely out of the box, we will finally need three small things. I am not sure in which package some of them should go, though. 1) An install? option to populate /etc/skel/ with the special permission directories private/(rwx--) and incoming/ (rwsrws-wt) 2) An option for addgroup to automatically create groupdirs for each created group: root: (rwxrwsr-x) /home/group/ root: (rwxrws---) /home/group//private root: (rwsrws-wt) /home/group//incoming http://bugs.debian.org/248130 3) A groupdir (like in 2) set up for the "users" system group. But where/how should those things be created best? Kind regards, Christian -- 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/20100601202300.7adee04bc.gatzeme...@tu-bs.de@tu-bs.de
users not belonging to the "users" group
There is another issue related to getting user collaboration working out of the box: Users do not belong to the "users" group, thus creating say /home/group/users as a (sgid) group directory to provide a way for the users of a system to collaborate on something does not work. Either adduser would have to add all new (and existing) users explicitly to the users group and fill /etc/group with all user names, or pam_group can dynamically add users to the users group when they login. Following the pam_group line for /etc/security/group.conf: *; *; *; Al-2400; users Any preferences? Cheers, Christian -- 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/20100601003237.3fdd1ea0c.gatzeme...@tu-bs.de@tu-bs.de
hashing username => UID
Am Mon, 31 May 2010 15:28:20 +0200 schrieb Marc Haber: > I really like the idea of having all "Debian-exim" accounts with the > same UID on all systems as this incredibly eases moving things As Yves suggested, maybe start testing a username => [1000..2] hash algorithm and conflict resolution scheme in a wrapper script, possibly merging the algorithm into useradd or adduser later. IMHO that would be a nice feature. Cheers, Christian -- 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/20100531160026.2d0ee9e6c.gatzeme...@tu-bs.de@tu-bs.de
Re: completeness of the upg tests
Am Mon, 31 May 2010 12:17:54 +0200 schrieb Harald Braumann: > > I believe this completes the checks (see below) > > I don't, and that is what I meant by wishful thinking. Nowhere is it > guaranteed that it works this way. Could you please be a little more specific and try to provide a counter example to the reasoning I included in that other message? So we can see what you mean. > pam-umask's usergroups options does the right thing in many cases. But > only the admin can know if the user database conforms to the necessary > critera. So do we know that pam_umask usergroups is perfectly safe with the debian default user database? Isn't what we are discussing here only whether (if an admin changes the debian default to another user database) a relaxation may occur unjustified or not? Umask relaxation should be 100% safe with the debian default user database and settings. So the conditional relaxation can stay enabled by default. (As it was from the beginning. The functionality is only now available again with pam_umask.) We all agree a fixed 002 umask is not good, and that change should just be reverted as soon as possible. But in cases where an admin changes the database to a non-default one, it is perfectly fine for him to also have to turn umask relaxation off to make things work, if the user database does not conform to the common criteria. No matter if that means setting a fixed "abc" or "aac" umask in the resulting system. IMHO umask relaxation can be enabled by default in debian, even if there is an example where the umask would get relaxed unjustified with some non-default non-debian or even rogue user data base. It's just that all the legitimate examples I could come up with, won't get an unjustified relaxed umask anyway with the completed tests. Cheers, Christian -- 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/20100531154435.43367925c.gatzeme...@tu-bs.de@tu-bs.de
Re: same UIDs across multiple systems
Am Sun, 30 May 2010 20:13:31 +0200 schrieb Luk Claes: > > I guess you should have a deeper look into the possibilities of nss so > you don't need to sync /etc/passwd and similar files across systems, Ah thanks, you were thinking NIS networked shared database. I was thinking, say if I would give you an account on my box "Luk Claes" would compute to say ID 14314, the same as on your system. Independent from any type of networked setup. Not a 100% sync, since any conflicts will need to be resolved, but quite good for systems with sparse users. Also for reinstalling/replacing systems, because it makes the IDs independent from the order in which they were created. Cheers, Christian -- 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/20100530204622.51110686c.gatzeme...@tu-bs.de@tu-bs.de
Re: setgid umask override versus global umask change
Am Sun, 30 May 2010 09:44:49 -0700 schrieb Mike Bird : > This would seem to be a trival kernel patch, whether implemented > alone or together with a /sys control to enable/disable it. > > Can anyone see any downside? I guess the interface would be quite different. Checking the current umask and overriding it if needed are standard procedures for apps. Other than that, it seems it would not allow shared access to $HOME or files in any other non-sgid directories with a multiple member private group. Do you see a security hole in granting user permission for the group after the suggested UPG tests (instead of a global umask change)? Cheers, Christian -- 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/20100530202555.26181f99c.gatzeme...@tu-bs.de@tu-bs.de
same UIDs across multiple systems
Am Sun, 30 May 2010 15:02:41 +0100 schrieb Stephen Gran : > There are already well understood mechanisms for ensuring that uids > are the same across multiple systems. I don't think adduser is the > place for that. Do you have a debian pointer maybe? I am asking because the following suggests a central tool that handles debians passwd data. 9.2.1: "Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow." I found useradd (not adduser) is part of passwd (not base-passwd), would that be that central tool to take care of debian requirements? Cheers, Christian -- 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/20100530195713.6199b03cc.gatzeme...@tu-bs.de@tu-bs.de
hashing username => UID
Am Sat, 29 May 2010 16:51:10 +0200 schrieb Marc Haber : > hash the user name into the UID since this will - at least on systems > with only a handful of users - enhance the chance that the same user > name will get the same UID on different systems. That could be quite nice, yes. -- 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/20100530115005.5f9e2786c.gatzeme...@tu-bs.de@tu-bs.de
completeness of the upg tests (was: test if primary group, with only implicit membership of the user?)
Thank you Harald for scrutinizing. Am Fri, 28 May 2010 14:50:27 +0200 schrieb Harald Braumann: > On Fri, May 28, 2010 at 11:30:25AM +0200, C. Gatzemeier wrote: > > I'm not sure yet, if I do properly understand the point when/why > > relaxing conditionally is a bad idea. To me, setting *fixed* umasks > > with group permissions equaling user permissions seems worse, > > especially because not all users of a system need to be set up with > > UPGs. > > Why would you create such a mixed system? I don't see a usecase for > that. If the system is UPG it should be UPG for everyone. Ideally yes. However we have to consider that non-upg users can be preexisting (system users even) or get imported somehow. But more importantly people can get into this situation simply by changing the adduser/useradd's UPG setting after some users have been created. > if users are managed externally, then nothing is > guaranteed. All the assumptions about name or id equalities are > nothing more than that: assumption. > > Therefore this autodetection will fail for all systems that don't > conform to pam-umask's idea about user and group set-up. If that externel system means to have UPGs, but does not support propper ID allignment (like debian, at least in the last releases), one will have to fix it or set a fixed umask, yes. Same can be true in cases where a custom site-wide UPG user database is used. In this case, exactly as you wrote, manually setting a default umask is an option, if the IDs are not alligned or the user is explicitly added to his primary group. > And in those > cases where it fails, I'd expect it to fail only for specific cases > that might go unnoticed for a long time and might be hard to analyse. It's probably better if these are cases where the umask hasn't been relaxed, than cases where a fixed 002 umask is to permissive. This is a case for the 022 default with "usergroups" relaxation. Then if one has UPGs, but notices the umask is not 002 for some users, one checks login.defs and is informed about the checks and given a way to set a fixed umask. However in case the external System properly supports alligned IDs (RH, etc.) I currently don't see where any rare cases of misbehaviour in either way should come from. The tests should work equally well even with "mixed usersgroups". Just like on the external system itself. If the external user database is non-UPG, this is the case where the tests prove most useful and provide security over setting a system wide 002 umask as a default. (Additionally it is a case where the admin can choose to turn umask relaxation off for peace of mind.) To shield against any cases of username==groupname (say a "vip" user and group, or any other case of matching initials) where only coincidently UID==GUID match, I asked to check if "vip" is the primary group of the "vip" user and "vip" user is not an explicit member of the "vip" group. I believe this completes the checks (see below), while it supports user private groups that consist of multiple members. An example can be family members that can be fully trusted and one wants to give access to almost everything in $HOME (which should not be a sgid directory), or abstract sub-users (used by programs) like "accounting" which data is accessable by members of the accounting department. > So anyone with some conscience for security will immediately disable > this source of indeterminism and set the umask to a fixed value. I > know I will. That is OK, by rather setting a system wide fixed 002 umask you can be sure users authenticating against an external system will get a umask that can be too permissive. It may still make sense, as you have more knowledge/control about the local environment than the debian system. > So one thing is the change of the default value. Debian delivers a UPG scheme, and to deliver it functional umask 002 is required. But setting 002 as a _global_default_ is too much. That's why the default umask stayed 022 when UPGs where introduced in distros, and is only relaxed conditionally. > I'd say keep the > default at the most secure value. But the world won't end if it is > changed. Supporting the UPG features with a system wide umask would IMHO be a bad idea. Even if the admin may allways think of changing it, a fixed umask won't cut it for "mixed systems" where some (system) users do not have UPGs. > But the other thing > is this auto detection that is only based on wishful thinking and just > adds complexity and indeterminism. I'd really rather Debian wouldn't > do this. Then we just see things differently here, I would consider it wishful thinking to rely on admins to be able to manually set the correct umask for all individ
Re: test if primary group, with only implicit membership of the user?
Am Fri, 28 May 2010 08:37:05 +0100 schrieb Roger Leigh: > Calling getgrgid/getgrnam and > checking that the user list is empty is *ensuring* that it's private, > at least at the point in time we check (we can't predict the future). > > This check would protect against adding other users to UPGs, Yes, if we'd check for an empty user list, that would break the "sub-users" feature. Say if "me" wants to run iceweasel under the user "me-iceweasel", you can simply "adduser me me-iceweasel" without breaking the UPGs scheme (in contrary, benefitting from it when working with sub-user files, because me-iceweasel can still get umask 002) while not having to set a fixed relaxed umask. If there are other users in the users' private group, IMHO we just can and should assume they are there intentionally. So the test may only look for the fact that the user is _itself_ not an explicit member of his primary group. That would not be the case if the group was created as a regular group for collaboration (like the "users" group, or any other) and users are added to it. > at least > from the POV of not relaxing the umask (it's still a bad idea). I'm not sure yet, if I do properly understand the point when/why relaxing conditionally is a bad idea. To me, setting *fixed* umasks with group permissions equaling user permissions seems worse, especially because not all users of a system need to be set up with UPGs. I think for an inappropriate relaxations to occur, the user/group info would have to come from some external system. If we test username==groupname, and GUID==UID (it seems to be a standard among UPG systems to allocate cleanly alligned group IDs) and if we can add to this the test if the user is not an explicit member of his primary group (for all db backends?) that looks like a pretty firm while flexible test to me. It's only unfortunate that debian's "useradd", that it does not allays allign IDs, hasn't been seen as such earlier, but it is on its way to be solved. Kind regards, Christian -- 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/20100528113025.7661e2cac.gatzeme...@tu-bs.de@tu-bs.de
adduser or useradd (package passwd)?
Am Wed, 26 May 2010 08:40:26 +0100 schrieb Stephen Gran: > first useful argument I've heard for changing adduser's > behavior. Interoperability with other software is a useful goal, Would the change have to go into adduser or useradd (part of base-passwd)? 9.2.1: "Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow." -- 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/20100528112324.5c5a5f83c.gatzeme...@tu-bs.de@tu-bs.de
test if primary group, with only implicit membership of the user?
> > 2) A special case is true: The group is set as the main group of the >user (in /etc/passwd) while the user is NOT added to his group >in /etc/groups. May pam_umask test this, for umask relaxation? -- 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/20100528010045.653c9121c.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Am Fri, 28 May 2010 00:15:17 +0200 schrieb "C. Gatzemeier" : > but now, if we > activate pam_umask, it will read UMASK 022 from login.defs again (and > relax it conditionally). err, that is the case if you keep the UMASK 022 and "usergroups" option (the defaults). Of course you can set a fixed UMASK 002 and remove "usergroups" from the pam_umask call, and there will be no umask relaxation. -- 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/20100528002702.7b5741a4c.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Am Thu, 27 May 2010 11:35:34 +0200 schrieb Wolodja Wentland: > why not make the decision to use UPG explicit by setting > "UPG = True" I would say UPGs are already explicitly used. If your UPG = True means that newly created users are created with user private groups, than that is "USERGROUPS=yes" in adduser.conf. This UPG usage prerequisite, has been a debian default since 94' according to an old thread that was mentioned. If by UPG = True you refer to being conservative and relaxing the umask only for users that are created with certain characteristics that indicate that they really have been created with private user groups, thatn that used to be "USERGROUPS_ENAB yes" in login.defs until PAM was introduced whithout support for it, at that time, and broke it. Now pam_umask is available and takes the option "usergroups" when called from a pam.d/ config file (it could probably be patched to read login.defs). If by UPG = True you refer to setting a system wide default (relaxed) umask 002 (and risking to do to much to exsiting users or users on other systems authenticating agains the debian system), that used to be UMASK 002 in login.defs before PAM, with PAM "umask 002" had to be called from each shell rc file used, but now, if we activate pam_umask, it will read UMASK 022 from login.defs again (and relax it conditionally). -- 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/20100528001517.29cea841c.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Am Tue, 25 May 2010 16:43:21 -0700 schrieb Steve Langasek : > I am not willing to diverge from upstream on this as this > would mean admins coming from other systems may get an unpleasant > surprise when they find that Debian gives a more relaxed umask than > they were expecting in some corner cases. Would you, or somebody else, be willing to write a patch for pam_umask to read the USERGROUPS_ENAB option from /etc/login.defs or /etc/default/login, just as it is reading the UMASK option from there? Cheers, Christian -- 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/20100527010259.4fe10b74c.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Wed, 26 May 2010 23:26:37 +0200, Tollef Fog Heen: > Perhaps addgroup > shouldn't use the same gid range as what we are using for users, to > make this problem at least smaller, if not make it go away. Hm, that may be another option to allign UIDs and GIDs, you'd create split max. UID/GID amounts though, and would still need adduser/useradd to skip any available GIDs with old/manually taken UIDs to ensure UID==GUID UPG accounts. -- 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/20100527004121.6b029358c.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Am Wed, 26 May 2010 14:25:58 +0200 schrieb Michael Banck : > On Wed, May 26, 2010 at 02:36:53AM +0200, C. Gatzemeier wrote: > > Am Tue, 25 May 2010 22:47:51 +0200 > > schrieb Harald Braumann : > > > On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote: > > > > The path into your home directory is not restricted, just as the > > > > path others can take to ring your bell at home is not > > > > restricted. > > > > > > Depends on adduser settings. Both, world readable and private home > > > directories are common. > > > > Thanks! Adding ...the path to your home *is by default* not > > restricted,... seems to be more precise. > > In light of UPG, we might want to revisit the default here as well, > maybe it makes sense to have your $HOME not world-readable be the > default? Just making a list of consequences to consider here. Users can not modify the permissions of their home on their own, but they can manage everything within their home. The UPG scheme works directory based. So for private things, there should be a ready to use and set up ~/priv directory by default. That is a place where a user may keep much of his stuff, if he does not want to change permissions of other subdirs. As world readable is a largely used default programs with really privacy relevant config files should take care of their config file permissions already. If the $HOME however is not world accessible you can not have your ~/incoming or ~/Public directory within your home. More importantly users can not create new group directories on their own in their home, and they can not be allowed write access to a separate place like /home/group for this. When I'd set up an ISP/hosting system where users are not supposed to collaborate and work on their own, I'd change the default home permissions in adduser.conf. There is also some discussion about the home permission on https://wiki.ubuntu.com/MultiUserManagement Cheers, Christian -- 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/20100527001837.6bfdd866c.gatzeme...@tu-bs.de@tu-bs.de
GID/UID algorithm? (Re: The story behind UPG and umask.)
Am Wed, 26 May 2010 18:05:32 +0100 schrieb Roger Leigh : > How will adduser cope with group addition; does it skip UIDs until > it finds an unused unique UID/GID pair? Maybe just skip taken GIDs by default? (every user has one, less gap more likely to be usable for a user account), starting +1 from the highest GID that was ever created without specifying specific IDs on the system (to avoid giving possibly remaining old files from deleted users/groups to new users/groups). Set that search start pointer back to MIN_GID if it points to MAX_GID. If the admin hasn't manually created any users/groups with higer IDs, the first (+1) GID should already be an available slot. The UIDs and GIDs match nicely, occasionally (where a regular group has been created) some UIDs will stay unused. There shouldn' be any drawback. Does adduser rely on useradd? -- 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/20100526232358.17ffb67fc.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Am Wed, 26 May 2010 18:05:32 +0100 schrieb Roger Leigh : > What, exactly, does comparing the UID and GID get you? I.e. what > is is protecting you against? If you're using a system such as > Debian, which has created a group by the same name for many years, > you're in no danger AFAIU it is meant for cases where you connect a debian box to an existing LDAP etc. environment, where a user and group might exits but not be related. Like a user that is called admin and an admin system group etc. Having alligned UIDs==GIDs makes UPGs systems more distinguishable from other systems. The check will also recognize RH, f, ... UPGs systems, and the allignment will make those other systems also recognized a debian server as an UPG system. Cheers, Christian -- 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/20100526232212.1047deefc.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Am Tue, 25 May 2010 23:30:49 +0100 schrieb Stephen Gran : > adduser has had bugs filed in the past asking for uid to be equal to > gid by default, and I have so far rejected them as not worth the > complexity for the aesthetic pleasure of having numbers match. Is > there some problem with username == primary group name? I think ensuring UID==GID by default allows having automatic umask relaxation for UPGs to work and not compromising security, even in corner cases when the system is setup in other environments. Besides making UPGs and permissions more cleanly visible/detectable/adjustable on removable filesystems or tarballs (where you can only see numerical IDs). Cheers, Christian -- 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/20100526024848.3e6888dec.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Am Tue, 25 May 2010 22:47:51 +0200 schrieb Harald Braumann : > On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote: > > > The > > path into your home directory is not restricted, just as the path > > others can take to ring your bell at home is not restricted. > > Depends on adduser settings. Both, world readable and private home > directories are common. Thanks! Adding ...the path to your home *is by default* not restricted,... seems to be more precise. > > > All this can work because the primary group of each user is set to a > > private user group (UPG) by default. > > This is a bold assumption. In a system where user management is > external (e.g. LDAP), anything is possible and there are no defaults. We were just stating different assumptions, yes. Maybe also adding ...this can work in a default installation because...? > > > According to [1,2] a UPG is identifiable by > > This is wrong. There is no way to differentiate UPG - non-UPG. But I'm > repeating myself ... I've gone though your related posts that I found on the web. (Wasn't subscribed before, so answering here.) OK, the definitionn is wrong, or not complete, in the sense that it does not catch all possible UPGs. The auto-umask adjusing feature won't work for all possible UPG implementations, but it should work safely for the default debian installation, without compromising security in other environments. So yes, you can setup UPGs with UID!=GID, but then you'll also have to set the umask manually to make it work (globally or in gecos or ldap etc.). The UID==GID and username==groupname restriction of the pam_umask's "usergroups" option ensures that the umask is only relaxed automatically in very specific defined cases. That's why I'am thinking the UID==GID restriction pam_umask makes (and login made before) can be sane choice. (Others seem to use it also, and it is upstream.) The mentioned three points of the current implementation I found on the web even allow intentional addititions of users to the UPG as a quick way to set up trusted (sub-)users without requiring extra groups and groupdirs to work with files in your sub-user's account. And it allows proper removal of a UPG together with the user, if it is unused. > Let me quote from the comments in /etc/login.defs: > > #UMASK 022 is the "historical" value in Debian for UMASK when it was > used Right, that UMASK value was commented out when it needed to be dispersed into shell rc files, due to PAM not supporting "usergroups" yet. And below that comes "USERGROUPS_ENAB yes" which also "historicaly" did adjust the umask for UPG users. Of course we agree that UPGs and all related automatic umask adjustment should be configurable, i.e. they can be disabled. Cheers, Christian -- 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/20100526023653.46c6bc5cc.gatzeme...@tu-bs.de@tu-bs.de
proper umask default setting / disabling UPGs / release notes / steps to take
The umask used to be (and should be again now) settable centrally. (/etc/login.defs or /etc/default/login LSB?) Setting the umask in /etc/profile and multiple other rc files (instead centrally in login.defs) was only necessary while pam_umask was not available, and to be depreciated. All the times since 94' http://lists.debian.org/msgid-search/m0piquw-0002dgc.ijack...@nyx.cs.du.edu until PAM was included without support for it, the login package seems to have done the umask adjustment for UPG users, that pam_umask is requested to do again, now that it is available. To disable UPGs you currently need to change two settings, one in in /etc/login.defs and one in /etc/adduser.conf. So for a release note draft we can note: * A link to a (maybe improved version) of the users perspective on UPGs. https://wiki.ubuntu.com/MultiUserManagement * That existing users with UPG will now again get a correct UPG-default-umask. * That since existing users should have been set up with UPGs by the debian defaults all the time, this should be no security compromise. * That a central UMASK setting is now again possible in login.defs that can do a much better job than the umask lines in existing /etc/profile files etc. * That all umask settings have to be removed from preexisting /etc/profile ~/.bashrc and other shell rc files to take advantage from the improvements. * The option to disabling UPGs alltogether in adduser.conf and login.defs. As for a list of steps to do: 1) remove/comment out any umask settings in all shell configuration files shiped in debian (i.e. /etc/profile) and add a comment pointing to the right place for the global default umask setting. It might be /etc/default/login (LSB?), pam_umask looks at both. 2) Adjust /etc/login.defs: Refer to the text from: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/487729) Correct the comment about USERGROUPS_ENAB (now used by pam_umask). Or point to /etc/default/login (LSB?), pam_umask looks at both. UMASK 022 should be set in login.defs or /etc/default/login, and pam_umask's usergroups feature should be mentioned in the comment. 3) Enable pam_umask by fixing the issues related to the first couple of points of the howto at https://wiki.ubuntu.com/MultiUserManagement If anyone knows where this umask/UPG/multi-user issue is tracked, could you please add this accordingly? Kind regards, Christian -- 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/20100526012624.3b063ed1c.gatzeme...@tu-bs.de@tu-bs.de
The story behind UPG and umask.
Hi, am glad UPGs and the default umask finally got some momentum. Technical issues below. For anybody who has any doubt about UPGs or thinks it's insecure, here is a explanation snippet from [0]: ~ (This should be true, but still needs the fixes from below.) It is easy for multiple users to collaborate on debian systems. Just keep in mind that access permission to a file always depends on the permissions of the file itself AND the permissions of the directory path to it. By default files are readable for whoever has access to them, just as paper files are, but not writeable. If you don't want others to read your files, keep them in a private/ subdirectory. The path into your home directory is not restricted, just as the path others can take to ring your bell at home is not restricted. As a matter of fact you may post some files on your door, for others or to read. For example many programs read config files that you deposit in your home path. Besides, other users can drop files (for you personally) in your ~/incomming/ directory. All this can work because the primary group of each user is set to a private user group (UPG) by default. (A group without any mentioned members in /etc/group, named equal to the user.) This allows to grant write permissions to created files for the group by default. No one exept the owning user will be able to write to the file. Exept that is, if it has been created in a group directory... Group directories (directories with the set-group-id flag set) are special places (that again all users are able to visit) where the members of the group that owns the directory can write files in it. According to the set-group-id flag files created in the group directory will belong to the creating user who wrote the file and to the group *the directory belongs to*. The result is that all members of the group can work on the files in a groupdir of theirs. Other than that, group directories work just like home directories. So if a file for example should be readable only by group members, again put it into a private subdirectory. Group directories may be set up by regular users in their home directories, or by the system administrator or (automatically) by the addgroup command under /home/group. ~~ It seems things quite used to work before PAM was introduced while it didn't support any UPG detection at that time, but now pam_umask is here to help us out and we get the chance to fix it better then before. Some additions I'd like to make: * Things like ssh can and should keep requiring private permissions! Instead tools/scripts should be patched to adequately write these files with the umask set accordingly. (If they are not already, simply by having them manually override the default umask.) According to [1,2] a UPG is identifiable by 1) A group of the same name as the username 2) A special case is true: The group is set as the main group of the user (in /etc/passwd) while the user is NOT added to his group in /etc/groups. 3) UID==GID was questioned to be a requrement, probably because it was seen that it isn't be enforced, but it can be of great help if you are looking at a filesystem (removable drive) without knowing the corresponding passwd/groups file. So maybe it is sane that UID==GID is a requirement, and its only an adduser bug when it does not skip IDs that have been taken by non UPG groups when creating users, and thus does not deliver that requirement. With 2) you can still see that the group has been set up as a UPG even if additional users are added to the group. Explicitly it allows to detect that: A) Those users were added intentionally to the UPG and the umask should still be set to 002. (In general you create separate groups to enable user collaboration on UPG systems, so tools may very well give a warning/hint about it if you try to add a user to a UPG.) B) The group can be deleted if the user is deleted. Kind regards, Christian [0]https://wiki.ubuntu.com/MultiUserManagement [1]https://bugs.launchpad.net/gst/+bug/488158 [2]http://lists.alioth.debian.org/pipermail/adduser-devel/2008-February/003161.html -- 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/20100525220935.201d11b8c.gatzeme...@tu-bs.de@tu-bs.de
Browser's and Distro's (was: SWR Iron: Chromium without the data-mining)
Am Tue, 18 May 2010 22:36:56 +0200 schrieb Christoph Anton Mitterer : > Hi. > > AFAIK, even Chrome has disabled most tracking stuff per default > (except those things which FF/etc. do too). You may be raising a good point. As it is now: the first thing firefox seems to do when it's run, is to connect to search engines and have them set cookies, then, there are "intelligent Bookmarks" that connect to aggregators, while no "cookie safe" (or "cs lite"), "noscript" and "better privacy" are installed and set up properly by default. And the website blocking feature even seems to send URL hashes somewhere by default. The receiver might even not need to compute that hash himself anymore to join that info into their database. I don't know, would that make users look as if they were sold to some company? They certainly seem exposed to any kind of tracking by default. Would it be a responsible and sane decision for any distribution to turn that off, while providing simple buttons to allow things selectively? (i.e. noscript option to enable scripts for particular sites one want's to use, but not for any goo-analytics goo-mail, goo-login, goo-website or flashy goo-toolkit someone was lured to inject into your browser.) I mean what do you think of a distro when you notice it started pushing all interactions with its websites to some goo-analytics tracking? With "so easy to use" social network clients ( i.e. with maybe only freebee fishnet like servers put up centrally, that track any business and social interactions) installed in a distro, at least you can choose not to use them. And you can work on implementing/improving alternative, easy to use free software tools that function in a distributed, peer based manner to help people connect in their real social network in more direct ways. But with browsers and websites set to injecting scripts, you actively need to turn things off. I'm really wondering about what you guys think of this. Kind regards, Christian -- 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/20100525204443.14237bcdc.gatzeme...@tu-bs.de@tu-bs.de
Re: Right Way to make a configuration package
Am Monday 18 October 2004 02:01 schrieb Enrico Zini: > One problem with diversion could also be that the original package's > scripts won't probably edit the diverted conffile, but would probably > edit the file in the traditional place instead. Same would be the case for admins and users, and their scripts, tools and utilities, right? Having only one authoritative config place is probably less prone to confusion. > > I suspect the only sensible way to do this is to implement multilevel > > configuration files in all applications we want to configure at > > install time. Multilevel config files would sure be nice, where the apps don't support them it might be sufficient to provide only multilevel *defaults*. Multilevel as application defaults, package defaults, system defaults (CDDs) and possibly admin defaults. That should be possible with any type of app configuration. Eeach level of authority could optionally provide a description of their defaults that are processed by a configuration helper as CFG that is designed to never interfere with user settings as described at http://freedesktop.org/Software/CFG Quickly brainstorming this, customizing a running system to a template (a CDD) could be a two step process of copying in the meta info and then interactively or not "resetting" to the new defaults. In new installations the settings could automatically default to the customization if the meta data is present early enogh. Kind Regards, Christian
