Previously Santiago Vila wrote:
> [ Maybe base-passwd is more apropriate for this than base-files ].
Or both: base-passwd to be sure the group exists, and base-files to
be sure write access is possible. Ugly, but it might be necessary.
Wichert.
--
===
On Thu, 10 Jun 1999, Wichert Akkerman wrote:
> Previously Joey Hess wrote:
> > Would it make sense for any packages that use the new permissions scheme
> > make sure they have proper perms in the postinst?
>
> I think letting base-files fix the permissions and letting other
> packages Depend on a
Previously Joey Hess wrote:
> Would it make sense for any packages that use the new permissions scheme
> make sure they have proper perms in the postinst?
I think letting base-files fix the permissions and letting other
packages Depend on a recent base-files version would be a better
solution. (or
Miquel van Smoorenburg wrote:
> But /var/log/wtmp and /var/log/lastlog don't belong to a package - how
> do we make sure the permissions on those files get changed? Should
> base-files take care of that ?
Would it make sense for any packages that use the new permissions scheme
make sure they have
In article <[EMAIL PROTECTED]>,
Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>+The files /var/run/utmp, /var/log/wtmp and
>+/var/log/lastlog should be installed writeable by group
>+utmp. Programs who need to modify those files should be installed
>+install setgid u
Marco d'Itri wrote:
> On Jun 08, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> >+ The files /var/run/utmp, /var/log/wtmp and
> >+ /var/log/lastlog should be installed writeable by group
> >+ utmp. Programs who need to modify those files should be installed
> >+ install setgid u
On Jun 08, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>+ The files /var/run/utmp, /var/log/wtmp and
>+ /var/log/lastlog should be installed writeable by group
>+ utmp. Programs who need to modify those files should be installed
>+ install setgid utmp.
Why lastlog too?
Previously Manoj Srivastava wrote:
> Could some one please supply the language to be finally
> included in the policy document?
How about this?
--- policy.sgml.org Tue Jun 8 17:10:09 1999
+++ policy.sgml Tue Jun 8 17:09:41 1999
@@ -2531,6 +2531,21 @@
+
Previously Manoj Srivastava wrote:
> Could some one please supply the language to be finally
> included in the policy document?
Certainly, I'll cobble somthing up later today.
> Has Brandens amendment been accepted?
Yes.
Wichert.
--
===
Hi,
http://www.debian.org/Bugs/db/37/37389.html
Could some one please supply the language to be finally
included in the policy document? The bug report is surprisingly
sparse. (I know I can, but I want to strictly separate the package
maintainence job, which does not involv
Previously Chris Waters wrote:
> I posted an objection that I thought we should check with a security
> expert to make sure there aren't any known security issues with this
> idea. I don't know if that's been done, but the moment it is, my
> objection will be (has been?:) withdrawn.
As a member o
n May 21, "Karl M. Hegbloom" <[EMAIL PROTECTED]> wrote:
>>> `minicom' is group owned by `uucp'.
>Marco> This is wrong. BTW, it's not even sgid, so I see no reason
>Marco> to chown the binary to the uucp group.
> Should it be `chgrp dialout', with o-x? Or root.root, o+x, and rely
> "Marco" == Marco d'Itri <[EMAIL PROTECTED]> writes:
Marco> On May 20, "Karl M. Hegbloom" <[EMAIL PROTECTED]>
Marco> wrote:
>> I've noticed that there is currently a `uucp' group, a `dip'
>> group, and a `dialout' group. Do we really need all three?
>> What is the
Mar
On May 20, "Karl M. Hegbloom" <[EMAIL PROTECTED]> wrote:
> I've noticed that there is currently a `uucp' group, a `dip' group,
> and a `dialout' group. Do we really need all three? What is the
Yes. uucp is used by the UUCP program, dialout owns the modem device and
dip can start pppd and dip.
At 18:37 -0700 1999-05-19, Karl M. Hegbloom wrote:
I'll second on official creation of the `utmp' group, even if none of
the other major Linux distributions are also doing this... though I
wonder if they are, and if they also call the group `utmp'. We ought
to use the same group name, even if n
I'll second on official creation of the `utmp' group, even if none of
the other major Linux distributions are also doing this... though I
wonder if they are, and if they also call the group `utmp'. We ought
to use the same group name, even if not all use the same standard GID
for that group. Is
On Sat, May 15, 1999 at 02:17:54PM -0700, Chris Waters wrote:
> > > Bug:
> > > Title: utmp group proposal
> > > Posted: 09 May 99
> > > Proposer: Wichert Akkerman
> > > Seconders: Branden Robinson, Joel Klecker, Ossama Othman, Raphael Hertzog,
Joseph Carter <[EMAIL PROTECTED]> writes:
> > Bug:
> > Title: utmp group proposal
> > Posted: 09 May 99
> > Proposer: Wichert Akkerman
> > Seconders: Branden Robinson, Joel Klecker, Ossama Othman, Raphael Hertzog,
> >Marco d'Itri, Joseph
[EMAIL PROTECTED] (Miquel van Smoorenburg) wrote:
>Zack Weinberg <[EMAIL PROTECTED]> wrote:
>>
>>Joel Klecker wrote:
>>>The main problem is that 2.0 kernels do not support sigaltstack(),
>>>this causes such things as m4 to fail when run on a Linux 2.0 system
>>>if it was compiled on a glibc 2.1 s
In article <[EMAIL PROTECTED]>,
Zack Weinberg <[EMAIL PROTECTED]> wrote:
>
>Joel Klecker wrote:
>>The main problem is that 2.0 kernels do not support sigaltstack(),
>>this causes such things as m4 to fail when run on a Linux 2.0 system
>>if it was compiled on a glibc 2.1 system using 2.2 kernel he
Joel Klecker wrote:
>At 19:15 -0400 1999-05-09, Michael Stone wrote:
>>On Sun, May 09, 1999 at 04:03:01PM -0700, Guy Maor wrote:
>>> Because it requires glibc 2.1 and kernel 2.2.
>>
>>Which reminds me, we should probably make it clear that 2.0 kernels will
>>not work properly with potato if we do
Previously Joel Klecker wrote:
> The main problem is that 2.0 kernels do not support sigaltstack(),
> this causes such things as m4 to fail when run on a Linux 2.0 system
> if it was compiled on a glibc 2.1 system using 2.2 kernel headers.
Which basically means that with potato we can't support
Previously Guy Maor wrote:
> Because it requires glibc 2.1 and kernel 2.2.
I was wondering why nobody from the m68k-camp started complaining here,
since I remember James Troup saying that m68k wouldn't switch to
glibc2.1 for some time?
Wichert.
--
===
Previously Jean Pierre LeJacq wrote:
> I have two concerns:
>
>* The proliferation of users/groups.
We're not the first doing this. I think RH6 also has a utmp group for
the same purpose. Anyway for security purposes I'll be happy to support
another user/group anytime.
Wichert.
--
On May 10, Joel Klecker <[EMAIL PROTECTED]> wrote:
>That is not correct, the UNIX98 pty interface in glibc 2.1 does not
>require a 2.2 kernel. grantpt() can use BSD ptys and the pt_chown
>program in the absence of kernel support for UNIX98 ptys.
So that means if I have /dev/pts I can chmod -s
On Sun, May 09, 1999 at 22:14:51 -0700, Joey Hess wrote:
> We also have to come up with some way to get /dev/pts/ mounted
> automatically, right?
No. Libc6 2.1.1-0.2 and newer already have a way (/etc/init.d/devpts.sh).
Ray
--
UNFAIR Term applied to advantages enjoyed by other people which we
At 19:15 -0400 1999-05-09, Michael Stone wrote:
On Sun, May 09, 1999 at 04:03:01PM -0700, Guy Maor wrote:
Because it requires glibc 2.1 and kernel 2.2.
Which reminds me, we should probably make it clear that 2.0 kernels will
not work properly with potato if we do this.
They won't work proper
At 16:03 -0700 1999-05-09, Guy Maor wrote:
Chris Waters <[EMAIL PROTECTED]> writes:
This seems like *such* an obvious solution to so many problems that I
find myself perplexed why this hasn't done before, by others.
Because it requires glibc 2.1 and kernel 2.2.
That is not correct, the UNIX
Michael Stone wrote:
> Which reminds me, we should probably make it clear that 2.0 kernels will
> not work properly with potato if we do this. Maybe a big blinking orange
> sign during installation or something. :)
Hm, the only ill effect will be that people won't show up in wtmp, it won't
entirel
Package: debian-policy
Severity: normal
On Sun, May 09, 1999 at 03:19:19AM +0200, Wichert Akkerman wrote:
> Now that we have working Unix98 ptys for all systems (except m68k,
> which doesn't want to move to glibc2.1 for some reason?) we no longer
> need to make a process setuid root just to create
On May 09, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> There is a slight problem though: utmp. Currently only root can
> update the utmp. To solve this I propose we create an utmp
> group and put in policy that programs that want to modify the
> utmp should be setgid utmp instead of setuid root
On Sun, May 09, 1999 at 04:03:01PM -0700, Guy Maor wrote:
> Chris Waters <[EMAIL PROTECTED]> writes:
>
> > This seems like *such* an obvious solution to so many problems that I
> > find myself perplexed why this hasn't done before, by others.
>
> Because it requires glibc 2.1 and kernel 2.2.
Whi
Chris Waters <[EMAIL PROTECTED]> writes:
> This seems like *such* an obvious solution to so many problems that I
> find myself perplexed why this hasn't done before, by others.
Because it requires glibc 2.1 and kernel 2.2.
Guy
On Sun, May 09, 1999 at 03:19:19AM +0200, Wichert Akkerman wrote:
> Now that we have working Unix98 ptys for all systems (except m68k,
> which doesn't want to move to glibc2.1 for some reason?) we no longer
> need to make a process setuid root just to create a new pty. This
> includes programs like
On May 09, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>There is a slight problem though: utmp. Currently only root can update
>the utmp. To solve this I propose we create an utmp group and put in
>policy that programs that want to modify the utmp should be setgid utmp
>instead of setuid root (
At 03:19 +0200 1999-05-09, Wichert Akkerman wrote:
> To solve this I propose we create an utmp group and put in
> policy that programs that want to modify the utmp should be setgid utmp
> instead of setuid root (unless root is needed for other purposes of
> course).
This seems like *such* an obvi
At 03:19 +0200 1999-05-09, Wichert Akkerman wrote:
> To solve this I propose we create an utmp group and put in
> policy that programs that want to modify the utmp should be setgid utmp
> instead of setuid root (unless root is needed for other purposes of
> course).
Seconded.
-Ossama
--
Oss
Le Sun, May 09, 1999 at 03:19:19AM +0200, Wichert Akkerman écrivait:
> There is a slight problem though: utmp. Currently only root can update
> the utmp. To solve this I propose we create an utmp group and put in
> policy that programs that want to modify the utmp should be setgid utmp
> instead of
At 03:19 +0200 1999-05-09, Wichert Akkerman wrote:
To solve this I propose we create an utmp group and put in
policy that programs that want to modify the utmp should be setgid utmp
instead of setuid root (unless root is needed for other purposes of
course).
Seconded.
--
Joel Klecker (aka Espy)
On Sun, May 09, 1999 at 03:19:19AM +0200, Wichert Akkerman wrote:
> I propose we create an utmp group and put in policy that programs that
> want to modify the utmp should be setgid utmp instead of setuid root
> (unless root is needed for other purposes of course).
Seconded.
--
G. Branden Robins
Now that we have working Unix98 ptys for all systems (except m68k,
which doesn't want to move to glibc2.1 for some reason?) we no longer
need to make a process setuid root just to create a new pty. This
includes programs like xterm.
There is a slight problem though: utmp. Currently only root can
41 matches
Mail list logo
