Hi Danny,
Danny Milosavljevic skribis:
> It's easily possible to recreate /etc/passwd from scratch if the uids are
> always specified in s and thus /etc/passwd would not need to
> be persistent state anymore. Right now everything from /etc/passwd except
> the uid and the comment is already spec
Hi Leo,
On Sat, Jan 2, 2021 at 10:35 AM Leo Prikler
wrote:
> Hello Jason,
> Am Samstag, den 02.01.2021, 09:52 -0500 schrieb Jason Conroy:
> > On Sat, Jan 2, 2021 at 9:29 AM Leo Prikler <
> > leo.prik...@student.tugraz.at> wrote:
> > > Hi Jason,
> > > Am Samstag, den 02.01.2021, 09:02 -0500 schri
Hello Jason,
Am Samstag, den 02.01.2021, 09:52 -0500 schrieb Jason Conroy:
> On Sat, Jan 2, 2021 at 9:29 AM Leo Prikler <
> leo.prik...@student.tugraz.at> wrote:
> > Hi Jason,
> > Am Samstag, den 02.01.2021, 09:02 -0500 schrieb Jason Conroy:
> > > On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler <
> > >
Hi Danny,
Am Samstag, den 02.01.2021, 16:04 +0100 schrieb Danny Milosavljevic:
> Hi Leo,
>
> > > Considering the goal of Guix, it's weird that with Guix, one
> > > needs to
> > > store&restore /etc/passwd at all. It's state, but not very
> > > useful
> > > one.
> > > I mean that's how it is right
Hi Danny,
Am Samstag, den 02.01.2021, 15:50 +0100 schrieb Danny Milosavljevic:
> [...]
> I agree, if in addition.
>
> (Or if a registry is undesireable, calculate the uids by user name.
> These are the possibilities. If hashing user names is too uncommon
> on
> UNIX elsewhere, I say that we have
Hi Danny,
On Sat, Jan 2, 2021 at 9:50 AM Danny Milosavljevic
wrote:
> > >From the solutions we do have so far, I believe that making user
> > > accounts an explicit part of service configuration (in what shape may
> > > still be up for debate),
>
> Not everything needs to be user configurable.
Hi Leo,
> > Considering the goal of Guix, it's weird that with Guix, one needs to
> > store&restore /etc/passwd at all. It's state, but not very useful
> > one.
> > I mean that's how it is right now--but it's still weird.
> > With /etc/shadow maybe there's a slightly better case, but note that
>
On Sat, Jan 2, 2021 at 9:29 AM Leo Prikler
wrote:
> Hi Jason,
> Am Samstag, den 02.01.2021, 09:02 -0500 schrieb Jason Conroy:
> > On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler <
> > leo.prik...@student.tugraz.at> wrote:
> > > Hi Danny,
> > > Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny
> >
Hi Jason,
On Sat, 2 Jan 2021 09:02:18 -0500
Jason Conroy wrote:
> My reaction to this was not that defaults are bad, but that dispersing
> numeric literals throughout the code is.
In general that is not exactly true. What you want is some way to check
the uids for collisions--and putting them
Hi Jason,
Am Samstag, den 02.01.2021, 09:02 -0500 schrieb Jason Conroy:
> On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler <
> leo.prik...@student.tugraz.at> wrote:
> > Hi Danny,
> > Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny
> > Milosavljevic:
> > > Hi Leo,
> > >
> > > On Sat, 02 Jan 2021 0
On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler
wrote:
> Hi Danny,
> Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny Milosavljevic:
> > Hi Leo,
> >
> > On Sat, 02 Jan 2021 00:16:45 +0100
> > Leo Prikler wrote:
> >
> > > > And it indeed is possible to add (uid 4711) in the literal and it
> > >
Hi Danny,
Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny Milosavljevic:
> Hi Leo,
>
> On Sat, 02 Jan 2021 00:16:45 +0100
> Leo Prikler wrote:
>
> > > And it indeed is possible to add (uid 4711) in the literal and it
> > > will work
> > > just fine.
> > I'm aware you're joking, or at lea
Hi Leo,
On Sat, 02 Jan 2021 00:16:45 +0100
Leo Prikler wrote:
> > And it indeed is possible to add (uid 4711) in the literal and it
> > will work
> > just fine.
> I'm aware you're joking, or at least I hope you are,
What? It's perfectly reasonable for a distribution to have stable system
us
Hi Leo,
On Fri, 01 Jan 2021 19:44:12 +0100
Leo Prikler wrote:
> Ah, that puts things into perspective. In other words, the problem is
> not, that Guix doesn't read /etc/passwd at all, but that it reads the
> wrong one (the host instead of the guest, so to speak). Should this
> perhaps be a par
Forgot to CC the ML.
--- Begin Message ---
Hi Danny,
Am Freitag, den 01.01.2021, 21:22 +0100 schrieb Danny Milosavljevic:
> Hi Leo,
>
> On Fri, 01 Jan 2021 19:44:12 +0100
> Leo Prikler wrote:
>
> > Ah, that puts things into perspective. In other words, the problem
> > is
> > not, that Guix doe
Hi Leo,
On Fri, 01 Jan 2021 19:44:12 +0100
Leo Prikler wrote:
> Ah, that puts things into perspective. In other words, the problem is
> not, that Guix doesn't read /etc/passwd at all, but that it reads the
> wrong one (the host instead of the guest, so to speak). Should this
> perhaps be a par
Hi,
Am Freitag, den 01.01.2021, 18:50 +0100 schrieb Danny Milosavljevic:
> Hello,
>
> On Fri, 01 Jan 2021 17:20:58 +0100
> Leo Prikler wrote:
>
> > I don't think changing the way UIDs are allocated by default is a
> > good
> > solution as that will break many running installations on real
> > h
Hello,
On Fri, 01 Jan 2021 17:20:58 +0100
Leo Prikler wrote:
> I don't think changing the way UIDs are allocated by default is a good
> solution as that will break many running installations on real
> hardware, that default to those.
(gnu build accounts), allocate-passwd defaults to keep usin
Hi Jason,
>Still, I wonder if this could introduce support challenges for packages that
>incorrectly assume UIDs are 16 bits wide, since they traditionally were that
>way in UNIX,
I don't think that these 16 bit problems are common at all since all the
getuid() syscalls I've ever seen, even in tr
Hi Danny,
Your idea has a definite elegance to it. :) I did not realize that Linux
supported 32-bit UIDs out-of-the-box. Still, I wonder if this could
introduce support challenges for packages that incorrectly assume UIDs are
16 bits wide, since they traditionally were that way in UNIX, and since
Hello Danny,
I don't think changing the way UIDs are allocated by default is a good
solution as that will break many running installations on real
hardware, that default to those. A better solution would be to make
user accounts and groups explicit configuration wherever account-
service-type is
Hi,
I agree that user ids and group ids should be made stable, even in general.
I, too, have been bitten by this. (So would everyone else if Guix touched
existing UNIX accounts in general)
The right way to make them stable is for Guix ot default each uid to the hash
of the user name.
That said
22 matches
Mail list logo
