Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
'Twas brillig, and Josh Triplett at 22/04/13 22:53 did gyre and gimble: On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. From what I gather what you're trying to solve here is a packaging problem - i.e. that multiple packages may have a requirement for a given user to exist and that if said packages are removed, the user should disappear again? If that is the case, then shouldn't the code actually be part of a packaging helper script rather than managed by a daemon? Also, if there is a .d folder setup here who owns those files? e.g. if I have postfix and cyrus-imapd packages, both will want the mail user. In that case who owns the /usr/lib/passwd.d/news file? They kinda both do need to provide that file, but that's wrong in and off itself - you'd be better creating a structure for this. Also the nothing uses the UID or GID anymore test is a bit hard is it not? I mean we'd have to check all file ownership and ACL entries on all mounted filesystems would we not? Sounds like a bad idea to me. All in all I still thing this is better handled by packaging helper scripts. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
2013/4/23 Josh Triplett j...@joshtriplett.org On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. :) realy need new bike? please see http://www.openwall.com/tcb/ This alternative to /etc/shadow in ALTLinux sinse 2000. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Alexey Shabalin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
2013/4/23 Alexey Shabalin a.shaba...@gmail.com 2013/4/23 Josh Triplett j...@joshtriplett.org On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. :) realy need new bike? please see http://www.openwall.com/tcb/ This alternative to /etc/shadow in ALTLinux sinse 2000. sorry, TCB support only shadow in different files, not passwd and group. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Alexey Shabalin -- Alexey Shabalin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 11:53 PM, Josh Triplett j...@joshtriplett.org wrote: 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. How would we notice showing up for system ids which will not go through pam? This will only work for things logging-in or authenticating otherwise, right? Or did you mean nss lookups? 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. How do we find out that there is nothing on the file system? 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. You mean user namespaces here? Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. How would installing a setgid tool from a package work? When would the tool get the right gid assigned at installation time? That stuff needs to be verifiable, we would record these ownerships somewhere else to be able to reproduce them? How do we cover the magic numbers recorded in the inodes of persistent filesystems? Unfortunately they don't work like 'tar' and have only the ids and not the names in it. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Tue, Apr 23, 2013 at 12:26 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 22.04.2013 23:53, schrieb Josh Triplett: 1) Leave only root in /etc/passwd and /etc/group why? 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs to break any compatibility? 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse oh yeah - break any known user management hence there are networks where admins since forever take care that user-id's uniqe all over the machine and you propose reuse? well, you have a solution in search of a problem More of this type of comments and you will have a problem posting on this list. If you are unable to moderate your style yourself, I will do that for you, no problem. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
Am 23.04.2013 13:33, schrieb Kay Sievers: On Tue, Apr 23, 2013 at 12:26 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 22.04.2013 23:53, schrieb Josh Triplett: 1) Leave only root in /etc/passwd and /etc/group why? 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs to break any compatibility? 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse oh yeah - break any known user management hence there are networks where admins since forever take care that user-id's uniqe all over the machine and you propose reuse? well, you have a solution in search of a problem More of this type of comments and you will have a problem posting on this list. If you are unable to moderate your style yourself, I will do that for you, no problem sorry but you are hyper-sensible there was no single bad word and Leave only root in /etc/passwd and /etc/group is a proposal which can not be a design target because it is from the sort of i propose to throw anything away how user-management works and any downstream distribution should change later with breaking any compatibility signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Tue, Apr 23, 2013 at 2:38 PM, Reindl Harald h.rei...@thelounge.net wrote: More of this type of comments and you will have a problem posting on this list. If you are unable to moderate your style yourself, I will do that for you, no problem sorry but you are hyper-sensible I just have enough of your attitude and comments. You are on moderation now. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Tue, Apr 23, 2013 at 01:45:32AM +0200, Tom Gundersen wrote: On Mon, Apr 22, 2013 at 11:53 PM, Josh Triplett j...@joshtriplett.org wrote: 1) Leave only root in /etc/passwd and /etc/group. Not commenting on the overall idea, but if you are going to do something like this, at least allow the the files not to exist at all, and in this case a default entry for the root user to be assumed. Sure, seems easy enough to make that entry synthetic as part of the PAM module. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
Am 22.04.2013 23:53, schrieb Josh Triplett: 1) Leave only root in /etc/passwd and /etc/group why? 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs to break any compatibility? 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse oh yeah - break any known user management hence there are networks where admins since forever take care that user-id's uniqe all over the machine and you propose reuse? well, you have a solution in search of a problem signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 11:53 PM, Josh Triplett j...@joshtriplett.org wrote: 1) Leave only root in /etc/passwd and /etc/group. Not commenting on the overall idea, but if you are going to do something like this, at least allow the the files not to exist at all, and in this case a default entry for the root user to be assumed. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 3:26 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 22.04.2013 23:53, schrieb Josh Triplett: 1) Leave only root in /etc/passwd and /etc/group why? 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs to break any compatibility? 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse oh yeah - break any known user management hence there are networks where admins since forever take care that user-id's uniqe all over the machine and you propose reuse? well, you have a solution in search of a problem It's ok if you don't understand the proposal, but there's no reason to post random uninformed criticism, now you're creating a rumor that something like this, if implemented, would break all user management. You don't know this. It doesn't exist yet. Maybe it will be 100% backward compatible. Why wouldn't it be? Maybe it won't even go anywhere because people who do understand the topic can assess it's viability. Can you please just wait and see if this goes anywhere concrete first? Thanks, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 02:53:50PM -0700, Josh Triplett wrote: +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Don't you want tcb, then? http://docs.altlinux.org/manpages/tcb.5.html -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
]] Josh Triplett Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. There's this pesky thing called file systems which are pretty reliant on UID and GID numbers. Also, if this is to be done, just put it in a separate NSS module, there's no need for integration with systemd here, AFAICS? (I don't really get what problem you're trying to solve, but that might just be me..) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] TODO: passwd.d, group.d
--- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. + Regularly: * look for close() vs. close_nointr() vs. close_nointr_nofail() -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
