Bug#582357: ITP: ocs -- Open Conference Systems: scholary conference management system

[Thijs Kinkhorst]

Package: wnpp
Severity: wishlist
Owner: Thijs Kinkhorst 

* Package name: ocs
  Version : 2.1.2-1
  Upstream Author : Public Knowledge Project
* URL : http://pkp.sfu.ca/?q=ocs
* License : GPL2 or later
  Programming Lang: PHP
  Description : Open Conference Systems: scholary conference management 
system

Open Conference Systems (OCS) is a Web publishing tool that will create a
complete Web presence for your scholarly conference. OCS will allow you to:

 * create a conference Web site
 * compose and send a call for papers
 * electronically accept paper and abstract submissions
 * allow paper submitters to edit their work
 * post conference proceedings and papers in a searchable format
 * post, if you wish, the original data sets
 * register participants
 * integrate post-conference online discussions


-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
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/20100520071330.12241.89283.report...@incagijs.uvt.nl

Bug#582359: ITP: histwi -- Histwi is a program for Twitter account management

[Bilal Akhtar]

Package: wnpp
Severity: wishlist
Owner: Bilal Akhtar 

* Package name: histwi
  Version : 0.5.3
  Upstream Author : Nikolay Blohin 
* URL : https://launchpad.net/histwi
* License : GPLv3
  Programming Lang: Python
  Description : Histwi is a program for Twitter account management

Histwi has the following features:
  * Download and save all your Tweets to a Database.
  * View and export all saved tweets to html or txt files.
  * Compare your Following to Followers.
  * Follow/Unfollow any of your friends.
  * Tracking new followers.
  * Advanced Twitter Search.
  * Manage multiple Twitter 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/20100520073754.4961.4236.report...@bilal-laptop

Re: Bug#582321: TAG: dirsum -- commandline directory summary

[Ron Johnson]

On 05/19/2010 05:36 PM, jaromil wrote:


Package: itp
Severity: wishlist
Version: 0.4;

* Package name : dirsum
Version : 0.4
Upstream Author : Dirk Bartley
* URL: http://code.dyne.org/?r=dirsum
* License: GNU GPL
Description: Dirsum is a command line tool to assist sorting out which
directories in a filesystem contain the most bytes.  It will sort
all of the subdirectories of a selected path according to the total
bytes of all files in them, including recursion through further
subdirectories and mounted partitions.



What does this do that existing tools don't?

$ du -Sk | sort -nr | head -n10
131960  ./.Newsletters.Washington_Post/cur
115332  ./.Lists.Debian.User.history.2007q1/cur
90704   ./.Lists.Debian.User.history.2007q2/cur
87364   ./.Lists.Debian.User.history.2005q3/cur
80544   ./.Lists.postgresql.history.2007h1/cur
77712   ./.Lists.postgresql.history.2007h2/cur
77540   ./.Lists.Debian.User.history.2006q2/cur
77024   ./.Lists.Debian.User.history.2006q1/cur
75464   ./.Miscelaneous/cur
75008   ./.Lists.Debian.User.history.2007q3/cur

--
Dissent is patriotic, remember?


--
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/4bf4ff10.6040...@cox.net

Re: SRWare Iron: Chromium without the data-mining

[Fabian Greffrath]

Am 18.05.2010 18:02, schrieb Ryan Oram:

Epiphany has iffy tabbed browsing support and the Javascript engine is
incomplete (I can't edit posts on many forums for example). It's a
great browser and should be worked on, but we should take as many
avenues as possible.


I don't see what you mean by "iffy" tabbed browsing, what's wrong with 
tabbed browsing in Epiphany? And regarding Javascript, I have never 
experienced the issues you describe. Are you sure you are using the 
latest packages (i.e. browser and webkit-engine) from unstable? Have 
you reported your issues upstream?



Epiphany is actually the default browser in infinityOS.


That's good to know.

Thanks,
Fabian



--
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/4bf4fe8a.20...@greffrath.com

Re: UPG and the default umask

[Santiago Vila]

On Thu, 20 May 2010, Roger Leigh wrote:

> On 19/05/2010 23:22, Santiago Vila wrote:
> > On Wed, 19 May 2010, Roger Leigh wrote:
> > 
> > > On 19/05/10 18:25, Santiago Vila wrote:
> > > > For the record: I've changed the umask setting in /etc/profile to this:
> > > > 
> > > > if [ "`id -u`" -ge 1000 ]; then
> > > 
> > > Should we also be catering for the reserved globally allocated UIDs in the
> > > range 6-64999 with this check (Policy §9.2.2)?
> > 
> > Hmm, good question. Can you give me an example of an uid which has
> > been allocated that way?
> 
> I'm not aware of any, TBH.  It's just a case where future use might cause
> potential vulnerabilities if not catered for as for UIDs <1000 since you'd be
> using 0002 where 0022 would be expected.
> 
> > Perhaps I should follow policy more closely, yes, but that would mean
> > using the range 1000-2 only, not 1000-5, as 3-5 is
> > "reserved" (whatever that means).
> > 
> > If an admin which runs out of UIDs in his system modifies
> > /etc/adduser.conf, will he remember to modify the upper bound in
> > /etc/profile as well?
> 
> Maybe the above check should source /etc/adduser.conf and use the values
> LAST_SYSTEM_UID and LAST_UID (or default to 0022 and then enable and 0002
> umask if in the range FIRST_UID to LAST_UID which is a bit simpler):
> 
> UMASK=0022
> # In a UPG setup, relax umask to 0002.
> if [ "$(id -u)" -ge "$FIRST_UID" -a "$(id -u)" -le "$LAST_UID" ]; then
>   UMASK=0002
> fi
> umask "$UMASK"

That would be much nicer, yes, but adduser is priority important and
base-files is required and essential, so that would not work if
adduser is removed, unless we make the code more complex again,
which I'm trying to avoid.

When adduser goes out of UIDs, this is what happens:

Adding user `somebody' ...
adduser: No UID/GID pair is available in the range 1000-1000 (FIRST_UID - 
LAST_UID).
adduser: The user `somebody' was not created.

So I agree that the sane thing to do here is, at least, to use the
same default range as /etc/adduser.conf (which in turn is the range
defined by policy).

I've just modified base-files accordingly to use the UID range 1000-2.

Thanks a lot for the input.


--
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/alpine.deb.1.10.1005201121130.18...@kolmogorov.unex.es

Bug#582370: ITP: netexplorer -- Gnome/Gtk Network animation tool

[syq]

Package: wnpp
Severity: wishlist
Owner: syq 


* Package name: netexplorer
  Version : 1.1a
  Upstream Author : Andrey Churin 
* URL : http://code.google.com/p/ns-3-shop/
* License : GPLv2
  Programming Lang: C++
  Description : Gnome/Gtk Network animation tool

  Network animation tool for ns3 on gtk platform.
  .
  At this moment only nam model (NetAnim) is supported.



-- 
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/20100520092415.7601.36552.report...@syq-laptop

Re: Bug#582321: TAG: dirsum -- commandline directory summary

[Yves-Alexis Perez]

On 20/05/2010 11:21, Ron Johnson wrote:
> hat does this do that existing tools don't?
> 
> $ du -Sk | sort -nr | head -n10
> 131960./.Newsletters.Washington_Post/cur

not sure dirsum can do that either, but it's painful that du itself
can't sort, since you can't use du -h before piping to sort.

Cheers,
-- 
Yves-Alexis


-- 
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/4bf5097e.80...@debian.org

Re: UPG and the default umask

[Raphael Hertzog]

Hi,

On Thu, 20 May 2010, Santiago Vila wrote:
> So I agree that the sane thing to do here is, at least, to use the
> same default range as /etc/adduser.conf (which in turn is the range
> defined by policy).
> 
> I've just modified base-files accordingly to use the UID range 1000-2.

I'm not sure this makes lots of sense.

hert...@alioth:~$ id -u maximilinux-guest
220227

There are many installations out there with large numbers of users that
simply can't respect the ranges set by the policy.

I would simply use a minimum of 500 or 1000 to differentiate system users
from normal users. adduser is not a required step to create accounts when
you manage your account database in LDAP/PostgreSQL (or whatever else).

Having a different behaviour betweent accounts simply because some are
above the maximal limits and some are below would be counter productive.

The policy was written when uid/gid were only 16 bits but our systems cope
with greater number of users nowadays... maybe the policy should be
revised on that point.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
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/20100520100849.gc8...@rivendell

Re: Bug#582321: TAG: dirsum -- commandline directory summary

[Ron Johnson]

On 05/20/2010 05:05 AM, Yves-Alexis Perez wrote:

On 20/05/2010 11:21, Ron Johnson wrote:

hat does this do that existing tools don't?

$ du -Sk | sort -nr | head -n10
131960./.Newsletters.Washington_Post/cur


not sure dirsum can do that either, but it's painful that du itself
can't sort, since you can't use du -h before piping to sort.



Eh?

Filters and do-one-thing-well utilities are The Unix Way.

--
Dissent is patriotic, remember?


--
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/4bf517e8.9020...@cox.net

Re: Bug#582321: TAG: dirsum -- commandline directory summary

[Patrick Schoenfeld]

On Thu, May 20, 2010 at 12:05:50PM +0200, Yves-Alexis Perez wrote:
> On 20/05/2010 11:21, Ron Johnson wrote:
> > hat does this do that existing tools don't?
> > 
> > $ du -Sk | sort -nr | head -n10
> > 131960./.Newsletters.Washington_Post/cur
> 
> not sure dirsum can do that either, but it's painful that du itself
> can't sort, since you can't use du -h before piping to sort.

Why not? What speaks against using:

du -h | sort -h

I think its suitable for that purpose.

Regards,
Patrick


-- 
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/20100520114115.ga9...@lisa

Re: Bug#582321: TAG: dirsum -- commandline directory summary

[Mika Pflüger]

Hi,

Am Thu, 20 May 2010 12:05:50 +0200
schrieb Yves-Alexis Perez :

> On 20/05/2010 11:21, Ron Johnson wrote:
> > hat does this do that existing tools don't?
> > 
> > $ du -Sk | sort -nr | head -n10
> > 131960./.Newsletters.Washington_Post/cur
> 
> not sure dirsum can do that either, but it's painful that du itself
> can't sort, since you can't use du -h before piping to sort.

Well, newer versions of sort added the functionality you miss, citing
from the GNU coreutils manual [1]:
‘-h’
‘--human-numeric-sort’
‘--sort=human-numeric’
Sort numerically, as per the --numeric-sort option below, and in
addition handle IEC or SI suffixes like MiB, MB etc (Block size).
Note a mixture of IEC and SI suffixes is not supported and will be
flagged as an error. Also the numbers must be abbreviated
uniformly. I.E. values with different precisions like 6000K and 5M
will be sorted incorrectly.

This feature was introduced in GNU coreutils release 7.5, 2009-08-20 [2]

As the coreutils version in debian sid and squeeze (I couldn't verify
lenny) is newer, the following command will work:
du -sh |sort -hr

to have the largest files first. the sort(1) man page on debian
documents this behaviour.

So if it only takes one pipe and coreutils to implement the
functionality of dirsum, maybe it's not worth a package.

Cheers,

Mika

[1]
http://www.gnu.org/software/coreutils/manual/coreutils.html#sort-invocation
[2]
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob_plain;f=NEWS;hb=1d10eb8b1eeff9dd0fe1bbbc212e9535203acff0,
search for '--human-numeric-sort'

-- 
Own your own computer. Don't use Windows 7. 


signature.asc
Description: PGP signature

Re: UPG and the default umask

[Christoph Anton Mitterer]

On Thu, 20 May 2010 00:22:02 +0200 (CEST), Santiago Vila 
wrote:
> If an admin which runs out of UIDs in his system modifies
> /etc/adduser.conf, will he remember to modify the upper bound in
> /etc/profile as well?
If these changes are going to be permanent and the discussion about them
has been aborted,... couldn't one grep the values out of adduser.conf?

Cheers,
Chris,


-- 
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/13f7ebc613bb2965e22bf960669d2...@imap.dd24.net

Re: Bug#582321: TAG: dirsum -- commandline directory summary

[Salvo Tomaselli]

On Thursday 20 May 2010 13:07:20 Ron Johnson wrote:
> Eh?
> 
> Filters and do-one-thing-well utilities are The Unix Way.

Fully agree on that! If one wants a do-everything-software can always use 
windows.

-- 
Salvo Tomaselli


signature.asc
Description: This is a digitally signed message part.

Re: Bug#582321: TAG: dirsum -- commandline directory summary

[Michal Politowski]

On Thu, 20 May 2010 06:07:20 -0500, Ron Johnson wrote:
> On 05/20/2010 05:05 AM, Yves-Alexis Perez wrote:
> >On 20/05/2010 11:21, Ron Johnson wrote:
> >>hat does this do that existing tools don't?
> >>
> >>$ du -Sk | sort -nr | head -n10
> >>131960./.Newsletters.Washington_Post/cur
> >
> >not sure dirsum can do that either, but it's painful that du itself
> >can't sort, since you can't use du -h before piping to sort.
> >
> 
> Eh?
> 
> Filters and do-one-thing-well utilities are The Unix Way.

So, alternatively, where is the filter converting 131960 to 128M?

-- 
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.


--
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/20100520111453.ga27...@meep.pl

Re: Bug#582321: TAG: dirsum -- commandline directory summary

[Ron Johnson]

On 05/20/2010 06:42 AM, Mika Pflüger wrote:

Hi,

Am Thu, 20 May 2010 12:05:50 +0200
schrieb Yves-Alexis Perez:


On 20/05/2010 11:21, Ron Johnson wrote:

hat does this do that existing tools don't?

$ du -Sk | sort -nr | head -n10
131960./.Newsletters.Washington_Post/cur


not sure dirsum can do that either, but it's painful that du itself
can't sort, since you can't use du -h before piping to sort.


Well, newer versions of sort added the functionality you miss, citing
from the GNU coreutils manual [1]:
‘-h’
‘--human-numeric-sort’
‘--sort=human-numeric’
 Sort numerically, as per the --numeric-sort option below, and in
 addition handle IEC or SI suffixes like MiB, MB etc (Block size).
 Note a mixture of IEC and SI suffixes is not supported and will be
 flagged as an error. Also the numbers must be abbreviated
 uniformly. I.E. values with different precisions like 6000K and 5M
 will be sorted incorrectly.



Well that's not The Unix Way!  ;)

--
Dissent is patriotic, remember?


--
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/4bf525bd.5070...@cox.net

Re: UPG and the default umask

[Peter Palfrader]

On Thu, 20 May 2010, Raphael Hertzog wrote:

> > So I agree that the sane thing to do here is, at least, to use the
> > same default range as /etc/adduser.conf (which in turn is the range
> > defined by policy).
> > 
> > I've just modified base-files accordingly to use the UID range 1000-2.
> 
> I'm not sure this makes lots of sense.
> 
> hert...@alioth:~$ id -u maximilinux-guest
> 220227
> 
> There are many installations out there with large numbers of users that
> simply can't respect the ranges set by the policy.
> 
> I would simply use a minimum of 500 or 1000 to differentiate system users
> from normal users. adduser is not a required step to create accounts when
> you manage your account database in LDAP/PostgreSQL (or whatever else).

System users can come out of ldap/NIS/etc too, and in such cases they
might not be in the 100-999 range either.

I fear anything which relies on ranges being used in some specific way
in deployed systems is fragile and prone to be wrong at least some of
the time.

-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
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/20100520121046.gs13...@anguilla.noreply.org

Re: UPG and the default umask

[Bastien ROUCARIES]

reopen 315089
thanks

On Mon, May 17, 2010 at 11:05 PM, Marvin Renich  wrote:
> * Aaron Toponce  [100517 13:05]:
>> On 05/17/2010 10:49 AM, Harald Braumann wrote:
>> > from pam_umask's description of the usergroups option:
>> >
>> > If the user is not root, and the user ID is equal to the group ID, *and*
>> > the username is the same as primary group name, the umask group bits
>> > are set to be the same as owner bits (examples: 022 -> 002, 077 ->
>> > 007).
>> >
>> > So if there is a mismatch of *either*, name or ID, then pam_umasks
>> > detects a non-UPG system, while it might very well be all UPG.
>>
>> A bug in pam_umask.so that needs to be addressed (which I believe we've
>> already started addressing in this thread).
>
> Bug #581984.

Closed by maintener and reopened, if we use libpam for umask it could
be even raised to RC critical, so please correct this behavior, report
upstream. I agree that it could be misleading for other distro in this
case, please add a newoption like useupg.

Thanks

Bastien


-- 
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/aanlktimvzj9octrxzidjc8kdzk6guhvedk5ssnrmo...@mail.gmail.com

Re: Bug#582321: TAG: dirsum -- commandline directory summary

[Yves-Alexis Perez]

On 20/05/2010 13:41, Patrick Schoenfeld wrote:
> Why not? What speaks against using:
> 
> du -h | sort -h
> 
> I think its suitable for that purpose.

Wow, thanks, I didn't know that. It doesn't exist in lenny coreutils, so
I guess it's not so old. You made my day :)

Cheers,
-- 
Yves-Alexis


-- 
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/4bf52b9b.30...@debian.org

Re: Bug#582321: TAG: dirsum -- commandline directory summary

[Peter Palfrader]

On Thu, 20 May 2010, Ron Johnson wrote:

> On 05/19/2010 05:36 PM, jaromil wrote:
>> * Package name : dirsum
>> Description: Dirsum is a command line tool to assist sorting out which
>> directories in a filesystem contain the most bytes.  It will sort
>> all of the subdirectories of a selected path according to the total
>> bytes of all files in them, including recursion through further
>> subdirectories and mounted partitions.
>>
>
> What does this do that existing tools don't?
>
> $ du -Sk | sort -nr | head -n10

Or, to compare it to something that my users can use too, what does it
offer over ncdu.

Cheers,
weasel
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
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/20100520123433.ga28...@anguilla.noreply.org

Re: UPG and the default umask

[Santiago Vila]

On Thu, 20 May 2010, Raphael Hertzog wrote:

> Hi,
> 
> On Thu, 20 May 2010, Santiago Vila wrote:
> > So I agree that the sane thing to do here is, at least, to use the
> > same default range as /etc/adduser.conf (which in turn is the range
> > defined by policy).
> > 
> > I've just modified base-files accordingly to use the UID range 1000-2.
> 
> I'm not sure this makes lots of sense.
> 
> hert...@alioth:~$ id -u maximilinux-guest
> 220227
> 
> There are many installations out there with large numbers of users that
> simply can't respect the ranges set by the policy.
> 
> I would simply use a minimum of 500 or 1000 to differentiate system users
> from normal users. adduser is not a required step to create accounts when
> you manage your account database in LDAP/PostgreSQL (or whatever else).
> 
> Having a different behaviour betweent accounts simply because some are
> above the maximal limits and some are below would be counter productive.
> 
> The policy was written when uid/gid were only 16 bits but our systems cope
> with greater number of users nowadays... maybe the policy should be
> revised on that point.

Yes, maybe we should modify policy.

But for now, current policy says UIDs over 3 are "reserved", which means
they might or might not be "ordinary user accounts".

Those who do not use "adduser" because "they know that they are doing"
will surely be able to change /etc/profile if the default one is not
suitable for them, as it happens with every default value in the system.

If we don't follow policy closely here, we can't claim that the umask
change does only affect "ordinary user accounts" (which is what I
think the release notes for squeeze will say).

So, I'm just providing a default which is consistent with other
defaults in the system and also with policy.

If by doing so we realize as a result that policy should be modified,
let us modify policy then.


-- 
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/alpine.deb.1.10.1005201408240.21...@kolmogorov.unex.es

Re: Bug#582321: TAG: dirsum -- commandline directory summary

[Ron Johnson]

On 05/20/2010 07:34 AM, Peter Palfrader wrote:

On Thu, 20 May 2010, Ron Johnson wrote:


On 05/19/2010 05:36 PM, jaromil wrote:

* Package name : dirsum
Description: Dirsum is a command line tool to assist sorting out which
directories in a filesystem contain the most bytes.  It will sort
all of the subdirectories of a selected path according to the total
bytes of all files in them, including recursion through further
subdirectories and mounted partitions.



What does this do that existing tools don't?

$ du -Sk | sort -nr | head -n10


Or, to compare it to something that my users can use too,


You could put that in an alias in /etc/profile.


  what does it
offer over ncdu.



--
Dissent is patriotic, remember?


--
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/4bf52e00.4060...@cox.net

Re: UPG and the default umask

[Marvin Renich]

* Bastien ROUCARIES  [100520 08:30]:
> reopen 315089
> thanks
> 
> Closed by maintener and reopened, if we use libpam for umask it could
> be even raised to RC critical, so please correct this behavior, report
> upstream. I agree that it could be misleading for other distro in this
> case, please add a newoption like useupg.
> 
> Thanks
> 
> Bastien

I have forwarded this upstream.
https://sourceforge.net/tracker/?func=detail&atid=106663&aid=3004656&group_id=6663

...Marvin


-- 
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/20100520124737.gb4...@cleo.wdw

Re: UPG and the default umask

[Bastien ROUCARIES]

On Tue, May 18, 2010 at 4:16 PM, Harald Braumann  wrote:
> On Tue, May 18, 2010 at 03:40:06PM +0200, Bastien ROUCARIES wrote:
>> On Tue, May 18, 2010 at 3:12 PM, Harald Braumann  wrote:
>> > On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote:
>> >> On 2010-05-18, Christoph Anton Mitterer  wrote:
>> >> > Not to speak about, that UPG is anyway a questionable abuse of the
>> >> > user/group concept.
>> >> >
>> >> > Neither to speak about the fact, that in the 17 years debian exists
>> >> > now,... no majority missed that "feature" (apparently).
>> >>
>> >> So you present that as universal facts as if you've booked the truth
>> >> (possibly a bad translation of a German saying).
>> >>
>> >> I think that feature is useful for all those who don't want to mess
>> >> with ACLs.  If you are not allowed to use ACLs and don't have UPG
>> >> with sane umasks collaboration is painful (see e.g. Debian infrastrure
>> >> with all users being in group Debian and default umask 0022 which
>> >> leads to wrong permissions in setgid directories, with ACLs being
>> >> disallowed).  So indeed I got a script which does newgrp and
>> >> setting the umask for me which I run whenever I want to do release
>> >> tasks.  But it would be more sane if the user wouldn't have to
>> >> care about that.
>> >
>> > Let me quote from the comments in /etc/login.defs:
>> >
>> > # 022 is the "historical" value in Debian for UMASK when it was used
>> > # 027, or even 077, could be considered better for privacy
>> > # There is no One True Answer here : each sysadmin must make up his/her
>> > # mind.
>> >
>> > And that's exactly the problem: there is no one-size-fits-all
>> > for the umask. Yes, for collaboration in a setgid directory you'd have
>> > to use 002 and thanks to UPG this is possible without compromising
>> > security. But I consider this just a special case. There are
>> > cases where Debian runs in a non-UPG environment, where you can't use
>> > that umask. And I don't think that's uncommon. Think of a mixed
>> > environment with Windows, where you might have a samba domain in LDAP. And
>> > last time I checked, the smbldap-tools didn't support UPG.
>>
>> Could you fill a bug report against smbldap-tools ?
>
> There is already an upstream bug [0], but even if it get's
> implemented, that wouldn't magically change all systems out there
> running non-UPG
>
>>
>>
>> > So whatever value is used as the default, half of the users will have
>> > to change it anyway, to fit their needs. And in such a case, where
>> > there is no single optimal value, I'd rather have the most
>> > conservative as default.
>> >
>> > If the umask is 022 and you create a setgid
>> > directory and forget to change the umask, you will quickly realise
>> > that things are not working as expected and fix it. If the umask is
>> > 002 and you add your Debian system to a non-UPG environment and forget
>> > to change the umask, things will still work perfectly but you put all
>> > your files at risk and might not even realise it until it is too
>> > late.
>>
>> Why not add a security dialog and assistant for installing and
>> upgrading the system?
>> It will ease the transition and fit allt the need, documenting
>> drawbacks and advantages of each scheme ?
>
> A umask of 022 is the right choice for most people and at least
> doesn't put the others at risk. Everyone, who knows what a setgid
> directory is and how it works, will also know, that there are certain
> requirements on the umask. And the others really don't care, as long
> as their security is not compromised.
>
> There is really no need to force everyone to make a useless decision,
> just for the sake of a change to make life of a specific minority easier.
>
> Cheers,
> harry
>
> [0] http://gna.org/support/?2040

Reported as #582388

Thanks


--
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/aanlktik2ugx9aqzveuqjfiko6oqqaq6rcyhzoz_ea...@mail.gmail.com

Re: UPG and the default umask

[Michael Banck]

On Thu, May 20, 2010 at 02:34:30PM +0200, Santiago Vila wrote:
> But for now, current policy says UIDs over 3 are "reserved", which means
> they might or might not be "ordinary user accounts".
> 
> Those who do not use "adduser" because "they know that they are doing"
> will surely be able to change /etc/profile if the default one is not
> suitable for them, as it happens with every default value in the system.
> 
> If we don't follow policy closely here, we can't claim that the umask
> change does only affect "ordinary user accounts" (which is what I
> think the release notes for squeeze will say).

Wouldn't the other way round mean that we cannot claim that the umask
changes will affect *all* "ordinary user account"?


Michael


-- 
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/20100520142149.ga22...@nighthawk.chemicalconnection.dyndns.org

Re: UPG and the default umask

[Michael Banck]

On Wed, May 19, 2010 at 09:48:41PM +, Christoph Anton Mitterer wrote:
> On Wed, 19 May 2010 15:22:04 -0600, Aaron Toponce
> 
> wrote:
> > You've only mentioned that SSH won't operate if the write bit is set on
> > the keys or anything under the ~/.ssh/ directory. Can you explain how an
> > ssh client failing to connect to an external ssh server because of the
> > umask is compromising security on the system?
> 
> Simply read the mails and those from the other critics again, it's not
> only annoying for myself to repeat things over and over again but also for
> everybody else to read it again.
> Nevertheless just saying "everything's fine" or "you only complained about
> ssh" won't really solve the issues, but just help to wave these changes
> through.

The problem is that most of your mails started with "OMG Debian will
compromise security, you all suck" or a paraphrasing thereof, so most
people didn't bother to read your mails in full and never actually read
a reasonable argument why the default umask should not be changed for
UPG setups.


Michael


-- 
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/20100520142416.gb22...@nighthawk.chemicalconnection.dyndns.org

Re: UPG and the default umask

[Roger Leigh]

On Thu, May 20, 2010 at 02:34:30PM +0200, Santiago Vila wrote:
> On Thu, 20 May 2010, Raphael Hertzog wrote:
> 
> > Hi,
> > 
> > On Thu, 20 May 2010, Santiago Vila wrote:
> > > So I agree that the sane thing to do here is, at least, to use the
> > > same default range as /etc/adduser.conf (which in turn is the range
> > > defined by policy).
> > > 
> > > I've just modified base-files accordingly to use the UID range 1000-2.
> > 
> > I'm not sure this makes lots of sense.
> > 
> > hert...@alioth:~$ id -u maximilinux-guest
> > 220227
> > 
> > There are many installations out there with large numbers of users that
> > simply can't respect the ranges set by the policy.
> > 
> > I would simply use a minimum of 500 or 1000 to differentiate system users
> > from normal users. adduser is not a required step to create accounts when
> > you manage your account database in LDAP/PostgreSQL (or whatever else).
> > 
> > Having a different behaviour betweent accounts simply because some are
> > above the maximal limits and some are below would be counter productive.
> > 
> > The policy was written when uid/gid were only 16 bits but our systems cope
> > with greater number of users nowadays... maybe the policy should be
> > revised on that point.
> 
> Yes, maybe we should modify policy.
> 
> But for now, current policy says UIDs over 3 are "reserved", which means
> they might or might not be "ordinary user accounts".
> 
> Those who do not use "adduser" because "they know that they are doing"
> will surely be able to change /etc/profile if the default one is not
> suitable for them, as it happens with every default value in the system.
> 
> If we don't follow policy closely here, we can't claim that the umask
> change does only affect "ordinary user accounts" (which is what I
> think the release notes for squeeze will say).
> 
> So, I'm just providing a default which is consistent with other
> defaults in the system and also with policy.

I think using the user range defined by policy is fine for now.  At worst,
sites using the "reserved" and "reserved for Debian" ranges will get an
0022 umask for user accounts in this range until they change the user
range, i.e. no decrease in security.

> If by doing so we realize as a result that policy should be modified,
> let us modify policy then.

If all current Debian systems support a 32-bit UID and GID range, then
it would be great if we could amend Policy to move the reserved ranges
to the end of the 32-bit range rather than being at the end of the
16-bit range.  This would give a vast contiguous user range (4294931294
UIDs using the scheme below)

Likewise, 65535 is no longer a prohibited value; it's now (2^32)-1 =
4294967295, so Policy could also amend this restriction.

Additionally, user nobody would then be in the middle of the user
range; it could be shifted back to the end of the 32-bit range.


Suggestion for Policy:

0-99: Debian Global
100-999: Debian Dynamic
1000-4294932293: Users
[65534: nobody; could be moved to 4294967294 for new installs?]

4294932294-4294962293: Reserved
4294962294-4294967293: Debian Static Reserved
4294967294: nobody [new]
4294967295: (uid_t)(-1) == (gid_t)(-1) must not be used, because it is the 
error return sentinel value.

The ranges can be adjusted to make them tider if desired; this is just
adjusting the ranges as above, and drops the final (tiny) reserved range.
For example:

429490-429496: Reserved (6, was 30534)
429496-4294967293: Debian Static Reserved (7293, was 5000)


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: SRWare Iron: Chromium without the data-mining

[Ryan Oram]

On Thu, May 20, 2010 at 5:19 AM, Fabian Greffrath  wrote:
> I don't see what you mean by "iffy" tabbed browsing, what's wrong with
> tabbed browsing in Epiphany? And regarding Javascript, I have never
> experienced the issues you describe. Are you sure you are using the latest
> packages (i.e. browser and webkit-engine) from unstable? Have you reported
> your issues upstream?
>
>> Epiphany is actually the default browser in infinityOS.
>
> That's good to know.
>
> Thanks,
> Fabian

The tabbed browsing is greatly improved in 2.30. The forum post
editting bug seems to be isolated to vBulletin based-forums. I filled
a bug upstream: https://bugzilla.gnome.org/show_bug.cgi?id=619197

Right now, infinityOS uses Epiphany 2.28 as it's based on Ubuntu
Karmic, but we'll likely be upgrading to Epiphany 2.30 (with the new
WebKit libraries) in infinityOS 1.1 due to the tabbed browsing
improvements.

Thanks,
Ryan


-- 
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/aanlktilndqyn2qlvqxrom1hxdihukk8bqx02th-lz...@mail.gmail.com

Bug#582420: ITP: libpod-elemental-perlmunger-perl -- Perl module that rewrites Perl documentation

[Ansgar Burchardt]

Package: wnpp
Severity: wishlist
Owner: Ansgar Burchardt 
Owner: Ansgar Burchardt 

* Package name: libpod-elemental-perlmunger-perl
  Version : 0.093330
  Upstream Author : Ricardo SIGNES 
* URL : http://search.cpan.org/dist/Pod-Elemental-PerlMunger/
* License : Artistic or GPL-1+ (like perl)
  Programming Lang: Perl
  Description : Perl module that rewrites Perl documentation

 Pod::Elemental::PerlMunger is a role to be included in classes that rewrite
 the documentation of a Perl document, stripping out all the Pod, munging it,
 and replacing it into the Perl.

This is a dependency of libdist-zilla-plugin-podweaver-perl (ITP #582138).



-- 
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/20100520170701.12519.13361.report...@marvin.43-1.org

Re: UPG and the default umask

[Russ Allbery]

Roger Leigh  writes:

> If all current Debian systems support a 32-bit UID and GID range, then
> it would be great if we could amend Policy to move the reserved ranges
> to the end of the 32-bit range rather than being at the end of the
> 16-bit range.  This would give a vast contiguous user range (4294931294
> UIDs using the scheme below)

You can't move the static reserved space: it contains statically assigned
UIDs.  :)  That's the whole point of it.  We could change where we're
assigning future static UIDs and GIDs from, but I'm not sure it's worth
the effort given that there's always going to have to be a legacy reserved
space for the ones that were already assigned.

> Additionally, user nobody would then be in the middle of the user
> range; it could be shifted back to the end of the 32-bit range.

I don't think it's a good idea to let people assign 65535 to a regular
user.  That's been hardcoded as nobody in a vast number of UNIX systems
for decades.  Reusing that UID for other purposes in any sort of shared
infrastructure is almost certain to cause problems.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/877hmyiip8@windlord.stanford.edu

Who owns /var/log/lighttpd?

[Olaf van der Spek]

Hi,

Please CC me, I'm not on the list.

Who owns /var/log/lighttpd?
Lighttpd (running as www-data) expects to be able to create files in
this dir, so the dir is owned by www-data.
What is the recommended way to chown this? Chown manually in postinst?
In the init script? Is there any support for this in the packaging
tools?

It's about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563635
-- 
Olaf


-- 
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/aanlktilzgm_osaslfgl7t4uh4stv0alin2kd2jfte...@mail.gmail.com

Re: UPG and the default umask

[Roger Leigh]

On 20/05/2010 18:30, Russ Allbery wrote:

Roger Leigh  writes:


If all current Debian systems support a 32-bit UID and GID range, then
it would be great if we could amend Policy to move the reserved ranges
to the end of the 32-bit range rather than being at the end of the
16-bit range.  This would give a vast contiguous user range (4294931294
UIDs using the scheme below)


You can't move the static reserved space: it contains statically assigned
UIDs.  :)  That's the whole point of it.  We could change where we're
assigning future static UIDs and GIDs from, but I'm not sure it's worth
the effort given that there's always going to have to be a legacy reserved
space for the ones that were already assigned.


Do we have any actual users of this space?  I didn't see anything in 
Policy.  Is there a central database listing the assignments?  If so, 
where may it be found?


In the absence of any existing static assignments, I don't see any
issue with moving the range.  If there are assignments, could these
not be moved for new installs?


Additionally, user nobody would then be in the middle of the user
range; it could be shifted back to the end of the 32-bit range.


I don't think it's a good idea to let people assign 65535 to a regular
user.  That's been hardcoded as nobody in a vast number of UNIX systems
for decades.  Reusing that UID for other purposes in any sort of shared
infrastructure is almost certain to cause problems.


65534 is the UID for nobody.  Anything using the UID for nobody should 
be getting it through the libc functions as for any other user; does any 
code actually hardcode 65534?  IMO that's a bug if so.  Given that 
nobody can't create files except for in /tmp and other world-writable 
locations, there shouldn't be any issues with changing the UID/GID since 
nothing in the filesystem should be owned by them.  A quick check on my 
system shows just two locations:


drwxrwxrwt 2 nobody nogroup 4096 Jan 27  2009 /var/spool/cups-pdf/ANONYMOUS
drwxr-se-x root nogroup 63488 May  2 01:04 /usr/lib/kde4/libexec/kdesud

The first is totally pointless (bug filed), it could just be root:root 
and be even more safe.  The latter looks OK but should we really be 
having a file owned by nogroup in the filesystem at all on general 
principle?


Regarding 65535: Does any software actually hardcode the number 65535? 
Given that its only use is as an error return (-1) for uid_t and this is 
now a uint32_t any code hardcoding this value is already broken.


The main justification I would have for this change is that keeping the 
old 16-bit-constrained assignments fragments the 32-bit range space 
unnecessarily.  For checks such as being discussed, having a contiguous 
user range makes things much simpler for both us and admins.  I accept 
that we can't change things for existing systems where these are already 
being used, but it sucks to be stuck with a 16-bit legacy for evermore 
even for new installs.



Regards,
Roger


--
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/4bf58e18.3030...@codelibre.net

Re: UPG and the default umask

[Steve Langasek]

On Thu, May 20, 2010 at 08:31:36PM +0100, Roger Leigh wrote:
> Do we have any actual users of this space?  I didn't see anything in
> Policy.  Is there a central database listing the assignments?  If
> so, where may it be found?

/usr/share/doc/base-passwd/README

> The main justification I would have for this change is that keeping
> the old 16-bit-constrained assignments fragments the 32-bit range
> space unnecessarily.  For checks such as being discussed, having a
> contiguous user range makes things much simpler for both us and
> admins.  I accept that we can't change things for existing systems
> where these are already being used, but it sucks to be stuck with a
> 16-bit legacy for evermore even for new installs.

I don't think it's practical to ever get rid of the legacy UID range
fragmentation in the 16-bit space.  Better would be to plan a transition to
where we start numbering new user accounts from 65536 by default, instead of
from 1000.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: UPG and the default umask

[Bastien ROUCARIÈS]

"Roger Leigh"  a écrit :

>On 20/05/2010 18:30, Russ Allbery wrote:
>> Roger Leigh  writes:
>>
>>> If all current Debian systems support a 32-bit UID and GID range, then
>>> it would be great if we could amend Policy to move the reserved ranges
>>> to the end of the 32-bit range rather than being at the end of the
>>> 16-bit range.  This would give a vast contiguous user range (4294931294
>>> UIDs using the scheme below)
>>
>> You can't move the static reserved space: it contains statically assigned
>> UIDs.  :)  That's the whole point of it.  We could change where we're
>> assigning future static UIDs and GIDs from, but I'm not sure it's worth
>> the effort given that there's always going to have to be a legacy reserved
>> space for the ones that were already assigned.
>
>Do we have any actual users of this space?  I didn't see anything in 
>Policy.  Is there a central database listing the assignments?  If so, 
>where may it be found?
>
>In the absence of any existing static assignments, I don't see any
>issue with moving the range.  If there are assignments, could these
>not be moved for new installs?
>
>>> Additionally, user nobody would then be in the middle of the user
>>> range; it could be shifted back to the end of the 32-bit range.
>>
>> I don't think it's a good idea to let people assign 65535 to a regular
>> user.  That's been hardcoded as nobody in a vast number of UNIX systems
>> for decades.  Reusing that UID for other purposes in any sort of shared
>> infrastructure is almost certain to cause problems.
>
>65534 is the UID for nobody.  Anything using the UID for nobody should 
>be getting it through the libc functions as for any other user; does any 
>code actually hardcode 65534?  IMO that's a bug if so.  Given that 
>nobody can't create files except for in /tmp and other world-writable 
>locations, there shouldn't be any issues with changing the UID/GID since 
>nothing in the filesystem should be owned by them.  A quick check on my 
>system shows just two locations:
>
>drwxrwxrwt 2 nobody nogroup 4096 Jan 27  2009 /var/spool/cups-pdf/ANONYMOUS
>drwxr-se-x root nogroup 63488 May  2 01:04 /usr/lib/kde4/libexec/kdesud
>
>The first is totally pointless (bug filed), it could just be root:root 
>and be even more safe.  The latter looks OK but should we really be 
>having a file owned by nogroup in the filesystem at all on general 
>principle?
>
>Regarding 65535: Does any software actually hardcode the number 65535? 
>Given that its only use is as an error return (-1) for uid_t and this is 
>now a uint32_t any code hardcoding this value is already broken.
>
>The main justification I would have for this change is that keeping the 
>old 16-bit-constrained assignments fragments the 32-bit range space 
>unnecessarily.  For checks such as being discussed, having a contiguous 
>user range makes things much simpler for both us and admins.  I accept 
>that we can't change things for existing systems where these are already 
>being used, but it sucks to be stuck with a 16-bit legacy for evermore 
>even for new installs.


Does it will break reading file from uid16 filesystem?

Regards

Bastien
>
>Regards,
>Roger
>
>
>-- 
>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/4bf58e18.3030...@codelibre.net
>

Re: UPG and the default umask

[Roger Leigh]

On 20/05/2010 20:44, Bastien ROUCARIÈS wrote:


"Roger Leigh"  a écrit :



The main justification I would have for this change is that keeping the
old 16-bit-constrained assignments fragments the 32-bit range space
unnecessarily.  For checks such as being discussed, having a contiguous
user range makes things much simpler for both us and admins.  I accept
that we can't change things for existing systems where these are already
being used, but it sucks to be stuck with a 16-bit legacy for evermore
even for new installs.



Does it will break reading file from uid16 filesystem?


This transition took place 10 years ago in the kernel and has been 
supported by all the mainstream filesystems since then; the minor ones 
may have also been fixed up.  This was fixed years ago, the most recent 
being fixing diskquotas.  Should be no problems in 2010!



Regards,
Roger


--
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/4bf59722.3080...@codelibre.net

Re: UPG and the default umask

[Roger Leigh]

On 20/05/2010 20:43, Steve Langasek wrote:

On Thu, May 20, 2010 at 08:31:36PM +0100, Roger Leigh wrote:

Do we have any actual users of this space?  I didn't see anything in
Policy.  Is there a central database listing the assignments?  If
so, where may it be found?


/usr/share/doc/base-passwd/README


Thanks.  Looking at the list, there's only 10 packages in total.  9 
create just one user/group, and one (qmail, which AFIACT isn't even in 
Debian) creates six.  I'm unsure why these 9 packages need a static 
allocation, given that every other service just creates/removes them 
dynamically.  Given the miniscule usage of this reserved range, is 
static allocation justifiable?



The main justification I would have for this change is that keeping
the old 16-bit-constrained assignments fragments the 32-bit range
space unnecessarily.  For checks such as being discussed, having a
contiguous user range makes things much simpler for both us and
admins.  I accept that we can't change things for existing systems
where these are already being used, but it sucks to be stuck with a
16-bit legacy for evermore even for new installs.


I don't think it's practical to ever get rid of the legacy UID range
fragmentation in the 16-bit space.  Better would be to plan a transition to
where we start numbering new user accounts from 65536 by default, instead of
from 1000.


Something probably best left until after Squeeze!  I think the simple 
check we have now will be robust enough until after then.



Regards,
Roger


--
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/4bf5976a.8080...@codelibre.net

Re: UPG and the default umask

[Russ Allbery]

Roger Leigh  writes:
> On 20/05/2010 18:30, Russ Allbery wrote:

>> You can't move the static reserved space: it contains statically
>> assigned UIDs.  :)  That's the whole point of it.  We could change
>> where we're assigning future static UIDs and GIDs from, but I'm not
>> sure it's worth the effort given that there's always going to have to
>> be a legacy reserved space for the ones that were already assigned.

> Do we have any actual users of this space?  I didn't see anything in
> Policy.  Is there a central database listing the assignments?  If so,
> where may it be found?

Steve got this part.

>>> Additionally, user nobody would then be in the middle of the user
>>> range; it could be shifted back to the end of the 32-bit range.

>> I don't think it's a good idea to let people assign 65535 to a regular
>> user.  That's been hardcoded as nobody in a vast number of UNIX systems
>> for decades.  Reusing that UID for other purposes in any sort of shared
>> infrastructure is almost certain to cause problems.

> 65534 is the UID for nobody.

Sorry, I meant 66534.  You're of course correct with 66535; you can't use
that on 16-bit UID systems, but otherwise it shouldn't be as much of an
issue.

> Anything using the UID for nobody should be getting it through the libc
> functions as for any other user; does any code actually hardcode 65534?
> IMO that's a bug if so.

Different sort of hard-code.  It's in tons of existing /etc/passwd files,
and giving another user the same UID as nobody (such as, for instance, a
mix of LDAP and local /etc/passwd data stores) can produce some nasty
security exposures depending on how nobody is being used.

> Given that nobody can't create files except for in /tmp and other
> world-writable locations, there shouldn't be any issues with changing
> the UID/GID since nothing in the filesystem should be owned by them.

By default, assuming use only of packages in Debian and no changes by
local administrators.  Those aren't good assumptions.

Changing a UID is a very big and disruptive change, and remember that a
lot of sites share UIDs site-wide.

> The main justification I would have for this change is that keeping the
> old 16-bit-constrained assignments fragments the 32-bit range space
> unnecessarily.  For checks such as being discussed, having a contiguous
> user range makes things much simpler for both us and admins.

I agree with Steve: the best way to provide a contiguous range is to start
in 32-bit space above our existing reservations.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87sk5m71it@windlord.stanford.edu

Sus Eventos Especiales en La Casona del Pollo

[La Casona del Pollo]

© informacion - Mercranet.com  ( 506) 24403726


Este boletín no tiene fines de venta directa, solo se  informa sobre 
promociones y descuentos disponibles y que usted pueda opinar sobre ellas. Si
usted desea solicitar información sobre las mismas entonces debe comunicarse 
con su proveedor. Si usted no consiente en recibir esta clase de
información por favor envíe una petición para poner fin a los avisos sobre 
promociones y descuentos que habrá disponibles. Si desea saber por qué
existe esta comunidad, por favor visite: Mercranet.com ( 
http://www.Mercranet.com )



 

 

 

 

 

 

 

 

 

 

 

 


Cambiar la suscripción (
http://mercranetpymes.com/index.php?option=com_acajoom&Itemid=999&act=change&subscriber=11803&cle=c4b71992bd71327e8969323a5058372a&listid=8
 )
De-suscribirse (
http://mercranetpymes.com/index.php?option=com_acajoom&Itemid=999&act=unsubscribe&subscriber=11803&cle=c4b71992bd71327e8969323a5058372a&listid=8
 )

Re: UPG and the default umask

[Roger Lynn]

On 19/05/10 22:20, Christoph Anton Mitterer wrote:
> btw: What happened to the idea of movin umask completely away from
> /etc/profile?
> I mean regardless of the discussion about UPGs and which value is the
> "best" default for umask, I found it to be a good idea to drop it there.

This is a good question. When I was changing my umask to 0002 a few
months ago web searches told me to look in login.defs, which told me to
use pam. So eventually I worked out how to change the umask in pam, but
it still didn't have any affect. It was only have further searching that
I discovered it was being overridden by /etc/profile.

Roger


-- 
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/4bf5bb38.6050...@rilynn.me.uk

Re: Bug#580814: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Russell Coker]

On Friday 14 May 2010 23:25:37 Scott James Remnant wrote:
> > Or just have per-user cgroups that a process is moved into when
> > logging in, see libpam-cgroup for something that does this.
> >
> > 
> 
> Then getty would respawn the second you login, stealing the controlling
> terminal from bash.

Why can't systemd use cgroups for monitoring daemons (the new functionality 
that wasn't in any previous Linux init system) and run getty's in the 
traditional manner?

It seems that cgroups offer significant benefits for some uses but not for 
every 
use.

Also what about sshd, telnetd, etc?  They can also have long-lived processes 
on behalf of users that are separate from the port listening functionality of 
the main daemon.


-- 
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/201005210851.06187.russ...@coker.com.au

Re: APT do not work with Squid as a proxy because of pipelining default

[Pierre Habouzit]

On Wed, May 19, 2010 at 03:28:00PM +0200, Bjørn Mork wrote:
> Pierre Habouzit  writes:
> > On Wed, May 19, 2010 at 10:42:55AM +0200, Bjørn Mork wrote:
> >
> >> 2) http proxy servers cannot always process pipelined requests due to
> >>the complexity this adds (complexity is always bad for security), and
> >
> > This is bullshit. It's *VERY* easy to "support" pipelining: parse one
> > request at a time, and until you're done with a given request, you just
> > stop to watch the socket/file-descriptor for reading (IOW you let the
> > consecutive request live in the kernel buffers).
> 
> Yeah, you make it sound easy.

The fact is that it is. And I know it from a fact having implemented
several custom http interfaces in the past. It's just _that_ easy.

And since it's _that_ easy, when the broken proxy is free software, it
shall be fixed.

-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


-- 
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/20100520231042.gb23...@madism.org

Re: Open then gates

[Russell Coker]

On Saturday 15 May 2010 22:07:44 Robert Klotzner wrote:
> There is a reason why things like selinux are developed.

http://en.wikipedia.org/wiki/Discretionary_Access_Control
http://en.wikipedia.org/wiki/Mandatory_access_control

Yes.  The design of Unix permissions is based on the DAC principle, allowing 
users to mess up and disclose their own confidential data or other people's 
data that they are entrusted with is part of the design.

With a MAC system such as SE Linux you can deny users the ability to 
inappropriately share data.  With SE Linux in Squeeze you will be able to 
control file based sharing via category sets and/or by assigning users to 
different SE Linux identities.  For user A to read data from user B the users 
will need to have the same SE Linux identity and user A will need to have a 
"level" in the MCS system that is equal or superior to the level of user B.

One of many possible uses of MCS would be to have a category for each user in 
a group and have their manager/teacher/whatever have the set of all categories 
to enable reading all their files.  Of course that simplistic model would only 
work in an organisation with less than 1024 users.


-- 
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/201005211015.14821.russ...@coker.com.au

Bug#582470: ITP: haskell-primitive -- Wrappers for primitive operations

[Marco Túlio Gontijo e Silva]

Package: wnpp
Severity: wishlist
Owner: "Marco Túlio Gontijo e Silva" 

* Package name: haskell-primitive
  Version : 0.3
  Upstream Author : Roman Leshchinskiy 
* URL : http://code.haskell.org/primitive
* License : BSD
  Programming Lang: Haskell
  Description : Wrappers for primitive operations

 This package provides a library for the Haskell programming language.
 See http://www.haskell.org/ for more information on Haskell.
 .
 This package provides wrappers for primitive array operations from GHC.Prim.



--
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/20100521000618.5981.98851.report...@zezinho

Work-needing packages report for May 21, 2010

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 598 (new: 1)
Total number of packages offered up for adoption: 122 (new: 2)
Total number of packages requested help for: 65 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   dvdrtools (#582378), orphaned today (non-free)
 Description: DVD writing program
 Installations reported by Popcon: 1132

597 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   b43-fwcutter (#581798), offered 5 days ago
 Description: Utility for extracting Broadcom 43xx firmware
 Reverse Depends: firmware-b43-installer firmware-b43-lpphy-installer
   firmware-b43legacy-installer
 Installations reported by Popcon: 1172

   linux-libertine (#581839), offered 4 days ago
 Description: Linux Libertine family of fonts
 Installations reported by Popcon: 1580

120 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apt-cross (#540341), requested 286 days ago
 Description: retrieve, build and install libraries for
   cross-compiling
 Reverse Depends: apt-cross emdebian-buildsupport emdebian-qa
   emdebian-rootfs emdebian-tools libemdebian-tools-perl
 Installations reported by Popcon: 357

   apt-xapian-index (#567955), requested 108 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: adept ept-cache
 Installations reported by Popcon: 11658

   ara (#450876), requested 921 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 110

   asymptote (#517342), requested 447 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 1272

   athcool (#278442), requested 2032 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 146

   boinc (#511243), requested 497 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1638

   cvs (#354176), requested 1547 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsservice (11
   more omitted)
 Installations reported by Popcon: 25376

   dctrl-tools (#448284), requested 936 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies debtree dlocate
   haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo
   simple-cdd ubuntu-dev-tools
 Installations reported by Popcon: 13662

   debtags (#567954), requested 108 days ago
 Description: Enables support for package tags
 Reverse Depends: debtags-edit goplay packagesearch
 Installations reported by Popcon: 2651

   dietlibc (#544060), requested 265 days ago
 Description: diet libc - a libc optimized for small size
 Reverse Depends: libowfat-dev
 Installations reported by Popcon: 238

   doc-central (#566364), requested 117 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 287

   dpkg (#282283), requested 2006 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: acct adacontrol advi advi-examples alien alqalam
   alsa-source am-utils-doc apt-build apt-cross (510 more omitted)
 Installations reported by Popcon: 91964

   elvis (#432298), requested 1046 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 399

   emdebian-tools (#540333), requested 286 days ago
 Description: emdebian crossbuilding tool set
 Reverse Depends: emdebian-buildsupport emdebian-qa emdebian-tools
   mlton-target-alpha-linux-gnu mlton-target-arm-linux-gnueabi
   mlton-target-hppa-linux-gnu mlton-target-i486-linux-gnu
   mlton-target-ia64-linux-gnu mlton-target-mips-linux-gnu
   mlton-target-mipsel-linux-gnu (4 more omitted)
 Installations reported by Popcon: 187

   fbcat (#565156), requested 127 days ago
 Description: framebuffer gr

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Russell Coker]

On Sunday 16 May 2010 03:35:09 Steve Langasek wrote:
> Given the difference in how kernels vs. init daemons are usually
> administered as part of a system, I think the runtime impact of supporting
> multiple LSMs in init is much more significant than supporting multiple
> LSMs in the kernel.  I don't think we want init to have shared lib deps
> for each of the available LSMs.

In the early days of LSM development there was the idea that LSM modules could 
be kernel modules, this idea was given up early on. The idea that modules 
could be "stacked" so that you could have multiple modules active at the same 
time (EG OpenWall /tmp protection as well as SE Linux) but that ended up not 
working well technically, so for ages it was only the Capability module that 
supported stacking.  A quick check of the dmesg on a testing system indicates 
that capability is not regarded as a separate module any more (or at least 
it's not in the dmesg).

The patch to the SysVInit for SE Linux is very small, it wouldn't be difficult 
to have support for a dozen such LSM modules with case statements.  Not that 
it would happen, the only LSM modules that are publicly available are SE 
Linux, Smack, AppArmor, and Tomoyo and I think that SE Linux is the only one 
that needs an init patch.


-- 
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/201005211053.37318.russ...@coker.com.au

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Russell Coker]

On Monday 10 May 2010 09:24:59 Steve Langasek wrote:
> And you don't have to use an initramfs; the same result could be achieved
> with a shim init on the root filesystem that does nothing but set up the
> SELinux context correctly and then exec upstart.

That's what I did years ago when we first stopped making the SE Linux kernel 
code load the policy from disk (kernel code isn't supposed to access files).  I 
had a shim named /sbin/init which loaded the policy (if necessary) and then 
executed init.  Of course that shim was run every time you ran "telinit u" 
which was a minor annoyance.

Another possible way of running it was to use the init=/sbin/shiminit option 
when booting the kernel, but some boot loaders (such as that of the Cobalt 
Qube I used for testing) made that unreasonably difficult.  Diverting init and 
changing the boot loader are both things it's best to avoid if possible.


-- 
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/201005211057.54568.russ...@coker.com.au

Bug#582473: ITP: haskell-vector -- Efficient Arrays for Haskell

[Marco Túlio Gontijo e Silva]

Package: wnpp
Severity: wishlist
Owner: "Marco Túlio Gontijo e Silva" 

* Package name: haskell-vector
  Version : 0.6.0.1
  Upstream Author : Roman Leshchinskiy 
* URL : http://code.haskell.org/vector
* License : BSD
  Programming Lang: Haskell
  Description : Efficient Arrays for Haskell

 This package provides a library for the Haskell programming language.
 See http://www.haskell.org/ for more information on Haskell.
 .
 An efficient implementation of Int-indexed arrays (both mutable and
 immutable), with a powerful loop fusion optimization framework.

 This is a dependency for haskell-criterion.



--
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/20100521004233.8938.81876.report...@zezinho

Re: Who owns /var/log/lighttpd?

[Paul Wise]

Probably the solution to that bug is to read the user from the
lighttpd configuration instead of hard-coding it. lighttpd -p can
probably help here. Not sure how you would parse the output though.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/aanlktiklkcnlkgdpq_ccftwrbexksab2qzf7dtoam...@mail.gmail.com

Re: UPG and the default umask

[Mike Bird]

On Thu May 20 2010 07:24:16 Michael Banck wrote:
> The problem is that most of your mails started with "OMG Debian will
> compromise security, you all suck" or a paraphrasing thereof, so most
> people didn't bother to read your mails in full and never actually read
> a reasonable argument why the default umask should not be changed for
> UPG setups.

Michael,

Those of us who actually administer Linux systems realize
that the proponents of this change are (a) way out of their
depth so that (b) they cannot forsee the consequences of
their actions yet (c) they have the power to carry their
actions through and (d) they haven't listened to reason yet.

So we just watch and laugh sadly and pray that we can keep
our systems secure.  Debian has survived worse and it will
survive this mess too.

--Mike Bird


-- 
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/201005201843.00651.mgb-deb...@yosemite.net

Re: UPG and the default umask

[Petter Reinholdtsen]

[Mike Bird]
> Those of us who actually administer Linux systems realize that the
> proponents of this change are (a) way out of their depth so that (b)
> they cannot forsee the consequences of their actions yet (c) they
> have the power to carry their actions through and (d) they haven't
> listened to reason yet.

Must be nice to be so confident about the errors of others.

Anyway, just as an interesting comment, this is what the RHEL 5 manual
have to say about user private groups and the default in RedHat and
Fedora:
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/s1-users-groups-private-groups.html
 >.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/2flocg923od@login1.uio.no

Re: UPG and the default umask

[Ben Finney]

Mike Bird  writes:

> Those of us who actually administer Linux systems realize that the
> proponents of this change are (a) way out of their depth so that (b)
> they cannot forsee the consequences of their actions yet (c) they have
> the power to carry their actions through and (d) they haven't listened
> to reason yet.

Out of interest, how would you propose an independent observer should
distinguish between these two cases:

* The package maintainers respond to specific expressed complaints,
  then ignore the complaints and fail to listen to reason.

* The package maintainers respond to specific expressed complaints,
  then consider the complaints and reject them on the basis of reason.

How would the independent observer tell which has occurred?

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\   Brain, but if we have nothing to fear but fear itself, why does |
_o__) Elanore Roosevelt wear that spooky mask?” —_Pinky and The Brain_ |
Ben Finney


-- 
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/874oi1hj55@benfinney.id.au