Your message dated Mon, 28 Jun 2010 05:17:09 +
with message-id
and subject line Bug#582495: fixed in debian-policy 3.9.0.0
has caused the Debian Bug report #582495,
regarding Drop 3-5 uid/gid reservation
to be marked as done.
This means that you claim that the problem has been dealt
This one time, at band camp, Stephen Gran said:
> This one time, at band camp, Russ Allbery said:
> > Clint Adams <[EMAIL PROTECTED]> writes:
> >
> > > We could add all or part of this range to the dynamic range.
> >
> > I think we should add all of 3-5 to the dynamic range. I'm sure
> >
This one time, at band camp, Russ Allbery said:
> Clint Adams <[EMAIL PROTECTED]> writes:
>
> > We could add all or part of this range to the dynamic range.
>
> I think we should add all of 3-5 to the dynamic range. I'm sure
> that Stanford isn't the only site that's already ignoring the
Clint Adams <[EMAIL PROTECTED]> writes:
> We could add all or part of this range to the dynamic range.
I think we should add all of 3-5 to the dynamic range. I'm sure
that Stanford isn't the only site that's already ignoring the Debian
reservation and using those UIDs for other purposes.
We could add all or part of this range to the dynamic
range.
I believe the 2^64-1 reservation suggestion is already covered by the
current wording.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Previously Joey Hess wrote:
> Well my proposed wording also recycles it, it just lets us get bits of
> it back from the admin in extreme circumstances.
In extreme circumstances we can always ask the admin no matter what
policy says.
Wichert.
--
Andreas Schuldei wrote:
> Joey, your package seems to be rather esoteric and could use ids
> from all over the place. It seems sensible to recycle the whole
> lot for the greater good.
Well my proposed wording also recycles it, it just lets us get bits of
it back from the admin in extreme circumst
Previously Andreas Schuldei wrote:
> actually, the idrange from 6-64999 could be used by joey,
> too, if we redifined it properly. it could say something like
> 'only on debian project owned machines'. (i understand the
> description of that id range to apply to those boxes, no reason
> to clog
* Andreas Schuldei ([EMAIL PROTECTED]) [020927 11:32]:
> i second Wichers original suggestion.
>
> Joey, your package seems to be rather esoteric and could use ids
> from all over the place. It seems sensible to recycle the whole
> lot for the greater good.
actually, the idrange from 6-64999
> Wichert Akkerman wrote:
> > We have reserved the 30000-59999 uid/gid range for ages, but never used
> > it and observing the current rate of growth I don't think it makes sense
> > to keep them reserved: Debian will not use that range in the next
> > century, wh
Previously Joey Hess wrote:
> What if we change the "Reserved" for 3-5 to "Reserved for use
> at local admin's discretion", and then something like my package can
> just ask[1] if it's ok to use a set in that range; an admin who is using it
> for something else like a large NIS or whatever
Thomas Bushnell, BSG wrote:
> Joey Hess <[EMAIL PROTECTED]> writes:
>
> > You really don't want to know, but in brief it runs many different
> > processes that need to be very isolated from each other and have very
> > different permissions given to them. I allocate the uids from the pool
> > on t
Joey Hess <[EMAIL PROTECTED]> writes:
> You really don't want to know, but in brief it runs many different
> processes that need to be very isolated from each other and have very
> different permissions given to them. I allocate the uids from the pool
> on the fly and use it for a kind of process
Wichert Akkerman wrote:
> Scary, why would it need so many uids?
You really don't want to know, but in brief it runs many different
processes that need to be very isolated from each other and have very
different permissions given to them. I allocate the uids from the pool
on the fly and use it for
Previously Joey Hess wrote:
> Well, I have a package that really needs a minumum of 100 but ideally
> 1000 semi-static uids of its own (the block should be contiguous; must
> have _no_ user in the password file for at least a large percentage of
> them; don't ask), but I have not dared to bring it
Wichert Akkerman wrote:
> We have reserved the 3-59999 uid/gid range for ages, but never used
> it and observing the current rate of growth I don't think it makes sense
> to keep them reserved: Debian will not use that range in the next
> century, while large systems defin
Package: debian-policy
Severity: wishlist
We have reserved the 3-5 uid/gid range for ages, but never used
it and observing the current rate of growth I don't think it makes sense
to keep them reserved: Debian will not use that range in the next
century, while large systems definitel
> Yes, but they're configurable at build time, which is problematic if the
> uid/gid is already taken on the system on which they're installed.
changeing the user name will also affect
- setuid programs
- crontab files, cron.daily/monthly/weekly files
- inetd.conf entries
- s
gt; > ups ups2
>
> no, please do not add another level of indirection.
> most daemons have configureable user id's anyway.
Yes, but they're configurable at build time, which is problematic if the
uid/gid is already taken on the system on which they're installed.
>
already taken)
> and so on. When you've found your name, you put it in the
> configuration file and that's it ! You've solved your problem.
I did see this solution. I just couldn't believe this is what we want all
the packages with system uid/gid to do.
Will we really force _this_
> This is common enough... should we perhaps create a system wide file, that
> maps default {user,group}names to local {user,group}names?
>
> eg, in /etc/local_names:
> mysql mysql
> ups ups2
no, please do not add another level of indirection.
most daemons have configureable user id's anyway.
On Tue, Aug 31, 1999 at 04:32:25PM +, David Coe wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
> I notice that mysql-server has the same situation; it creates or takes over
> the 'mysql' group and user, in the mysql-server.preinst file.
>
> (If I happened to have a user with that name before
Le Tue, Aug 31, 1999 at 03:03:50PM +0200, Jozef Hitzinger écrivait:
> Sorry to repeat the question,
No problem, but you could try to do something realistic and logical.
> What should the package do, when it uses dynamic system ids (recognized by
> name, not numeric value) and encounters a system,
-BEGIN PGP SIGNED MESSAGE-
I notice that mysql-server has the same situation; it creates or takes over
the 'mysql' group and user, in the mysql-server.preinst file.
(If I happened to have a user with that name before installing mysql-server,
I wouldn't be very happy.) I suspect that my
Hi,
>>"Jozef" == Jozef Hitzinger <[EMAIL PROTECTED]> writes:
Jozef> I think we will need list of reserved names, just as now
Jozef> there's list of reserved numbers _and_ names (0-99).
Since a list already exists, why not add the reserved names to
it, with no pre assigned IDs? Then we
On Tue, Aug 31, 1999 at 03:03:50PM +0200, Jozef Hitzinger wrote:
> I think we will need list of reserved names, just as now there's list
> of reserved numbers _and_ names (0-99).
I agree.
FWIW, I'd also like to see a list of what the rc3.d start and stop
priorities actually mean, as per the comme
Sorry to repeat the question,
but while my call for new static ids was shot down, nobody tried to answer
the question:
What should the package do, when it uses dynamic system ids (recognized by
name, not numeric value) and encounters a system, where the designed name
is already used by someone e
On Fri, 27 Aug 1999, Andreas Jellinghaus wrote:
> it is very easy in this case: don't use static id's. use dynamic.
I'm all for it, I'll patch what's needed and send it upstream etc.
> this is easy: use useradd or adduser to create an entry in /etc/passwd.
> these programs should return an error
> If I use static ids 0-99, they're set, both numbers and names. I can be
> sure, that on every debian system they're assigned the same (or
> unassigned, in case of older systems, and via dependencies I can force
> base-passwd to be updated) - stated in policy 3.2.
we should target compatibility t
Am I overlooking something? Please help me clarify this:
If I use static ids 0-99, they're set, both numbers and names. I can be
sure, that on every debian system they're assigned the same (or
unassigned, in case of older systems, and via dependencies I can force
base-passwd to be updated) - sta
30 matches
Mail list logo
