Re: A few observations about systemd

[Tino Keitel]

On Thu, Jul 21, 2011 at 22:44:55 +0200, Marc Haber wrote:

[...]

> Please don't get me wrong: I like the ideas behind systemd, but I need
> some more input to decide whether it's actually as flexible as an init
> script.

IMHO the flexibility of init scripts was often abused to do things
which should not be done in init scripts, leading to bugs because they
do too much things and try to be clever, becoming too complex in the
process.

This makes it hard to migrate to any alternative init system that
doesn't use init scripts. I'm using runit for some years now and had to
migrate a lot of init scripts to runit, often scratching my head when I
read those scripts.

Regards,
Tino


-- 
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/20110725064624.ga18...@mac.home

Bug#635310: ITP: libplack-middleware-session-perl -- Plack middleware component for session management.

[Dave Walker (Daviey)]

Package: wnpp
Severity: wishlist
Owner: "Dave Walker (Daviey)" 

* Package name: libplack-middleware-session-perl
  Version : 0.14
  Upstream Author : Tatsuhiko Miyagawa , Stevan Little 

* URL : http://search.cpan.org/dist/Plack-Middleware-Session/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Plack middleware component for session management.

 Perl module of Plack Middleware component for session
 management. By default it will use cookies to keep
 session state and store data in memory. This
 distribution also comes with other state and store
 solutions. It should be noted that it stores the
 current session as a hash reference in the
 psgix.session key inside the $env where you can
 access it as needed.



-- 
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/20110724225003.11349.27014.reportbug@localhost6

Re: A few observations about systemd

[Tollef Fog Heen]

]] Wouter Verhelst 

Hi Wouter,

| At any rate, by not wanting to do scripts, you're making life harder for
| yourself, since now you suddenly have to implement everything what
| people have trivially done in shell scripts for years in C. Writing
| flawless C isn't exactly easy either[1], and even if systemd's author is
| a perfect coder (which he isn't, since perfection does not exist),
| there's going to be a need to have some other people write some systemd
| module at some point in the future, since 'plain' systemd doesn't do
| what their software requires, or what their corporate environment likes,
| or whatever, and they're going to make mistakes.

There's not such thing as a systemd module.  (I assume you're not
talking about the systemd units which is the collective name for mounts,
services and so on.)

| And as a result, rather than have an initscript that does the
| equivalent of "killall -KILL -1", you're going to have someone
| implement socket enablement (or whatever it's called) incorrectly,
| thereby creating a remotely exploitable buffer overflow.

If you need socket activation, you obviously have to write the code to
do so.  There is nothing in systemd itself that requires you to use
socket activation unless it actually gains you something.

I have no idea why you are confusing the idea of stopping a service
using (or doing a reload) using killall and socket activation, unless
you're just doing this to rant, though.  Please grab me here at debconf
(or send email) if you're interested in having a discussion about it.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87r55fz4g8@qurzaw.varnish-software.com

Bug#635309: ITP: libirc-formatting-html-perl -- Perl module to convert between HTML and IRC formatting.

[Dave Walker (Daviey)]

Package: wnpp
Severity: wishlist
Owner: "Dave Walker (Daviey)" 

* Package name: libirc-formatting-html-perl
  Version : 0.29
  Upstream Author : Lee Aylward 
* URL : http://search.cpan.org/dist/IRC-Formatting-HTML/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to convert between HTML and IRC formatting.

 Provides two functions:
 - irc_to_html which takes an irc formatted string
 and returns the HTML version. Also takes an option
 to treat inverted text as italic.
 - html_to_irc which takes an HTML string and returns
 an irc formatted string.



-- 
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/20110724223846.11253.17489.reportbug@localhost6

Bug#635307: ITP: alice -- App::Alice - IRC client that is viewed in the web browser.

[Dave Walker (Daviey)]

Package: wnpp
Severity: wishlist
Owner: "Dave Walker (Daviey)" 

* Package name: alice
  Version : 0.19
  Upstream Author : Lee Aylward 
* URL : https://github.com/leedo/alice
* License : Artistic or GPL-1+
  Programming Lang: Perl & HTML/CSS
  Description : App::Alice - an Altogether Lovely Internet Chatting 
Experience.  Alice is an IRC client that is viewed in the web browser.

 IRC client that is viewed in the web browser. Alice runs
 in the background maintaining connections and collecting
 messages. When a browser connects, it will display the 100
 most recent messages for each channel, and update with any
 new messages as they arrive.
 .
 Alice also logs messages to an SQLite database. These logs
 are searchable through the web interface.
 .
 For desktop notifications install libdesktop-notify-perl.



-- 
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/20110724223112.11149.74415.reportbug@localhost6

Re: A few observations about systemd

[Simon McVittie]

On Sun, 24 Jul 2011 at 21:59:40 +0200, Wouter Verhelst wrote:
> even init.d has a documented (and what's
> more, actually *working*) implementation of not starting daemons at
> boot. It's called 'remove the *** symlink'.

If you remove them, they'll be recreated by the next upgrade; the right
way to disable an init script is to change the Snn links to K$((100 - nn)),
or in recent sysv-rc, "update-rc.d foo disable".

(I'm personally of the opinion that if experienced Debian developers
frequently get this wrong, we can't expect our users to get it right either...)

S


-- 
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/20110724215213.ga24...@reptile.pseudorandom.co.uk

Re: A few observations about systemd

[Russ Allbery]

Iustin Pop  writes:
> On Sun, Jul 24, 2011 at 01:17:50PM -0700, Russ Allbery wrote:

>> I don't get that impression.  Rather, I think both systemd and upstart
>> want to significantly reduce the involvement of shell scripts in the
>> boot process for the same reason that I'd love to have the time to
>> eliminate a lot of them from Debian package maintainer scripts: using a
>> (rather quirky with interesting portability issues) Turing-complete
>> programming language is only a good idea when you're doing things that
>> require that power.  The rest of the time, it's much harder to analyze,
>> much less adaptable (you're often duplicating work in every separate
>> script because helper systems lag, and if there's a bug, you have to
>> fix it everywhere instead of in one place), more complicated, and gives
>> people enough freedom to get themselves into trouble.

> Much less adaptable? Config files are fixed and non-extendable by
> themselves. A shell script, because it's Turing-complete, I regard as
> very adaptable.

We're talking about two very different things.  You're talking about
adaptability of the init script for a programmer who is modifying it.  I'm
talking about adaptability of a package already in the archive without
requiring someone go do work on it.

debhelper is an excellent example.  Notice how debhelper frequently just
fixes problems in every package that's using debhelper by fixing, say, the
generated maintainer script fragment?  That's the sort of adaptability
that I'm talking about.  When you have a simple descriptive language that
describes what the service should do, the entire archive can be adapted to
many forms of new behavior easily by changing the implementation of that
assertion.  This isn't possible if the code is implemented independently
in every init script; now you have to go modify every init script.

I think our experiences across the whole archive have shown that while
both cases certainly appear, for Debian as a whole the ability to adapt
the entire archive easily to some new circumstance is by far the most
common and most important case.

>> Falling back on such a language when you have to do something really
>> complicated is a good thing to support, but most of the time, you
>> really want to use a simple, declarative language that says what you're
>> trying to do and then implement the tools and support to accomplish
>> that in one, well-tested place.

> I have to disagree here. In my experience, most of the time such simple
> languages are not enough (down the road), and people will either start
> extending and extending them (at which point they're not simple
> anymore), or replace the solution entirely.

Well, I'm not sure what to say to that other than that my experience
directly contradicts yours.

-- 
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/8762mrbeew@windlord.stanford.edu

Re: A few observations about systemd

[Iustin Pop]

On Sun, Jul 24, 2011 at 01:17:50PM -0700, Russ Allbery wrote:
> Wouter Verhelst  writes:
> 
> > No. systemd wants to throw out init scripts, because they are shell
> > scripts, and Shell Scripts Are Bad!!!1!! oh noes.
> 
> I don't get that impression.  Rather, I think both systemd and upstart
> want to significantly reduce the involvement of shell scripts in the boot
> process for the same reason that I'd love to have the time to eliminate a
> lot of them from Debian package maintainer scripts: using a (rather quirky
> with interesting portability issues) Turing-complete programming language
> is only a good idea when you're doing things that require that power.  The
> rest of the time, it's much harder to analyze, much less adaptable (you're
> often duplicating work in every separate script because helper systems
> lag, and if there's a bug, you have to fix it everywhere instead of in one
> place), more complicated, and gives people enough freedom to get
> themselves into trouble.

Much less adaptable? Config files are fixed and non-extendable by
themselves. A shell script, because it's Turing-complete, I regard as
very adaptable.

> Falling back on such a language when you have to do something really
> complicated is a good thing to support, but most of the time, you really
> want to use a simple, declarative language that says what you're trying to
> do and then implement the tools and support to accomplish that in one,
> well-tested place.

I have to disagree here. In my experience, most of the time such simple
languages are not enough (down the road), and people will either start
extending and extending them (at which point they're not simple
anymore), or replace the solution entirely.

Turing complete → Config file → Turing complete → and so on… I think
that this cycle will go on and on, until we find a superior solution to
both.

regards,
iustin


signature.asc
Description: Digital signature

Re: A few observations about systemd

[Wouter Verhelst]

On Sun, Jul 24, 2011 at 10:16:15PM +0200, Stephan Seitz wrote:
> On Sun, Jul 24, 2011 at 09:59:40PM +0200, Wouter Verhelst wrote:
> >That this is not particularly useful is not specific to any init
> >implementation. I hate 'ENABLED=' configuration options with a passion.
> >They do not make *any* sense, even init.d has a documented (and what's
> 
> They do in packages that ships daemons and client tools. saslauthd,
> smartd or hddtemp are examples for such useful flags.

There is no excuse for them, any time. It *is* possible (and legal) to
install an init script that does not start by default, and does not
start from postinst.

At least that's my opinion on the matter.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20110724202045.gd6...@grep.be

Re: A few observations about systemd

[Russ Allbery]

Wouter Verhelst  writes:

> No. systemd wants to throw out init scripts, because they are shell
> scripts, and Shell Scripts Are Bad!!!1!! oh noes.

I don't get that impression.  Rather, I think both systemd and upstart
want to significantly reduce the involvement of shell scripts in the boot
process for the same reason that I'd love to have the time to eliminate a
lot of them from Debian package maintainer scripts: using a (rather quirky
with interesting portability issues) Turing-complete programming language
is only a good idea when you're doing things that require that power.  The
rest of the time, it's much harder to analyze, much less adaptable (you're
often duplicating work in every separate script because helper systems
lag, and if there's a bug, you have to fix it everywhere instead of in one
place), more complicated, and gives people enough freedom to get
themselves into trouble.

Falling back on such a language when you have to do something really
complicated is a good thing to support, but most of the time, you really
want to use a simple, declarative language that says what you're trying to
do and then implement the tools and support to accomplish that in one,
well-tested place.

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

Re: A few observations about systemd

[Stephan Seitz]

On Sun, Jul 24, 2011 at 09:59:40PM +0200, Wouter Verhelst wrote:

That this is not particularly useful is not specific to any init
implementation. I hate 'ENABLED=' configuration options with a passion.
They do not make *any* sense, even init.d has a documented (and what's


They do in packages that ships daemons and client tools. saslauthd, 
smartd or hddtemp are examples for such useful flags.



more, actually *working*) implementation of not starting daemons at
boot. It's called 'remove the *** symlink'.


Editing /etc/runlevel.conf is easy as well. But I still prefer the good 
old „exit 0” version. And talking with other people, this seems to be far 
easier to remember if they want to revert the change.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


signature.asc
Description: Digital signature

Re: A few observations about systemd

[Wouter Verhelst]

On Sat, Jul 23, 2011 at 01:09:02PM -0300, Fernando Lemos wrote:
> On Sat, Jul 23, 2011 at 12:47 PM, Marc Haber
>  wrote:
> > On Thu, 21 Jul 2011 18:12:13 -0300, Fernando Lemos
> >  wrote:
> >>A more realistic option would be launching a program (or script) which
> >>would read a configuration file (containing whatever
> >>/etc/default/exim4 contains nowadays) and launch the exim instance(s).
> >
> > So one would have some thing "like an" init script, which would
> > probably have to stay around and monitor the daemon? That doesn't look
> > like an easier way to do things.
> 
> The thing you don't seem to get is that systemd uses "init files"
> which are not really scripts.

No. systemd wants to throw out init scripts, because they are shell
scripts, and Shell Scripts Are Bad!!!1!! oh noes.

Personally, I think that's just silly, but YMMV.

At any rate, by not wanting to do scripts, you're making life harder for
yourself, since now you suddenly have to implement everything what
people have trivially done in shell scripts for years in C. Writing
flawless C isn't exactly easy either[1], and even if systemd's author is
a perfect coder (which he isn't, since perfection does not exist),
there's going to be a need to have some other people write some systemd
module at some point in the future, since 'plain' systemd doesn't do
what their software requires, or what their corporate environment likes,
or whatever, and they're going to make mistakes. And as a result, rather
than have an initscript that does the equivalent of "killall -KILL -1",
you're going to have someone implement socket enablement (or whatever
it's called) incorrectly, thereby creating a remotely exploitable buffer
overflow.

I'm sure there's a tradeoff here somewhere that makes all of this a good
idea, but I don't quite see it.

[1] Mind you, I'm not one of those loonies who thinks C should go the
way of the dinosaur. C has its uses, and I love doing C from time to
time; but "replacing shellscripts" isn't the first thing that comes
to mind when I think of "good projects to use C for".

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


signature.asc
Description: Digital signature

Re: A few observations about systemd

[Wouter Verhelst]

On Fri, Jul 22, 2011 at 05:09:11PM +0200, Michael Biebl wrote:
> A lot of those /etc/default files have a ENABLED=YES flags, which are not
> particularly useful with systemd, as systemd provides proper mechanisms to
> enable/disable services in a convenient way.

That this is not particularly useful is not specific to any init
implementation. I hate 'ENABLED=' configuration options with a passion.
They do not make *any* sense, even init.d has a documented (and what's
more, actually *working*) implementation of not starting daemons at
boot. It's called 'remove the *** symlink'.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


signature.asc
Description: Digital signature

Bug#638285: RFP: chan-datacard -- Asterisk PBX channel driver for Huawei UMTS cards

[Tzafrir Cohen]

Package: wnpp
Severity: wishlist


* Package name: chan-datacard
  Version : SVN snapshot (r187)
  Upstream Author : Artem Makhutov , 
Dmitry Vagin 
* URL : http://forge.asterisk.org/gf/project/chan_datacard/
* License : GPLv2
  Programming Lang: C
  Description : Asterisk PBX channel driver for Huawei UMTS cards
   channel driver for the Asterisk PBX that provides support for
   several Huawei UTMS cards and thus allows Asterisk to send and recieve
   SMS-es through them.


(Note: I seem to have forgotten to CC the message to the list, so faking
it. Sorry if there's any duplicate)

Technically this is mostly an ITP: I have something that should be a
working package (SVN: [1], binaries: [2]). However I don't have the
hardware and thus the package is completely untested.

I packaged it because I have recieved multiple requests that it should
be packaged. But I need someone with the hardware for at least testing
if you want it in Debian.

[1] http://anonscm.debian.org/viewvc/pkg-voip/chan-datacard/trunk/
[2] http://updates.xorcom.com/pkg-voip/repo-i386-sid/pool/main/c/chan-datacard/

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend


-- 
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/20110724175055.gm19...@pear.tzafrir.org.il

Bug#635283: ITP: openbgpd -- OpenBSD BGP routing daemon

[Jérémy Bobbio]

Package: wnpp
Severity: wishlist
Owner: Jérémy Bobbio 
User: debian-...@lists.debian.org
Usertags: kfreebsd

* Package name: openbgpd
  Version : 4.6+port4.9.20110612
  Upstream Author : Henning Brauer 
* URL : http://www.openbgpd.org/
* License : BSD
  Programming Lang: C
  Description : OpenBSD BGP routing daemon

OpenBGPD is a FREE implementation of the Border Gateway Protocol,
Version 4. It allows ordinary machines to be used as routers exchanging
routes with other systems speaking the BGP protocol.

-- 
Jérémy Bobbio.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Re: anyone interested in adopting ICU?

[Jay Berkenbilt]

Please reply to me directly (or CC me on replies) as I am not
currently subscribed to debian-devel.

Enrico Weigelt  wrote:

> * Jay Berkenbilt  schrieb:
>> 
>> I'm looking for someone who might like to take over the icu package.
>> This is ICU4C (C/C++), not to be confused with ICU4J (Java), which is a
>> separate package maintained by someone else.  ICU is "International
>> Components for Unicode".
>
> If it's not urgent, I'd like to take the job (need some time to set
> up an recent Debian build machinery again, as I didn't use it for
> almost a year now, and I'm little bit busy right now :().
>
> ICU4C is a little bit tricky case, as it tends to break ABI (sometimes
> even API) between releases, sometimes even semantic changes (at least
> had been the case in recent years). So I'd go for a full MVCc installation
> (IMHO better than Gentoo's slotting + revdep-rebuild approach ;-p).
>
> I'll yet have to pull it through my own embedded QM process and
> build machinery first, so we'll also get crosscompile fixups etc
> as a buy-product here ;-)

My offer stands, so if you'd like to take it, go right ahead.  There's a
problem right now with icu 4.8 in experimental on kfreebsd-amd64 that I
haven't been able to solve in the 20 minutes or so I spent trying to
figure it out.  Also, 4.8.1 has been released, and I have not packaged
yet.  There is an open bug for tracking the transition to 4.8, but
obviously these issues should be corrected first.

How long do you think it will be before you are ready to adopt the
package?  Maybe you can take a look at bug 630517 and see if you can
make some headway on it.

Also, are you a DD?  I can't find any indication that you are.  I am not
interested in sponsoring uploads (as I don't really have time to do the
reviews, etc.), so hopefully I have either overlooked your debian
account or you have sponsorship arrangements.

I have a local subversion repository with all my packaging stuff in it,
and I use svn-buildpackage against my local repository.  If you're
interested in a dump of that, let me know, and I can send it to you.

-- 
Jay Berkenbilt 


-- 
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/20110724091158.0304813597.qww314159@soup

Bug#635253: ITP: php-crypt-blowfish -- Allows for quick two-way blowfish encryption without requiring the MCrypt PHP extension

[Mathieu Parent]

Package: wnpp
Severity: wishlist
Owner: Mathieu Parent 

* Package name: php-crypt-blowfish
  Version : 1.0.1 or 1.1.0~RC2
  Upstream Author : Philippe Jausions , Matthew Fonda

* URL : http://pear.php.net/package/Crypt_Blowfish/
* License : BSD
  Programming Lang: PHP
  Description : Allows for quick two-way blowfish encryption without
requiring the MCrypt PHP extension

I'm packaging this, because it is needed by Horde_Secret (a core part of horde,
see horde.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/20110724120048.3088.22428.report...@tourthieu.sathieu.net

Re: Using -Werror in CFLAGS for a debian package build

[Bernhard R. Link]

* Russ Allbery  [110724 03:23]:
> > I, personally, consider all of those warnings bugs. Well, unused
> > variables aren't problems per se, but often can give good hints where
> > there *might* be some bug.
>
> Oh, sure, I agree.  But sometimes it's not a good idea to immediately
> escalate a whole ton of minor bugs to FTBFS bugs.

Especially as there are quite some gcc false positives, at least with
"uninitialized" warnings.

Bernhard R. Link


-- 
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/20110724115449.ga10...@pcpool00.mathematik.uni-freiburg.de

Re: Bug#634811: ITP: dillo -- fast and light web browser based on FLTK 1.3

[Axel Beckert]

Hi,

Adam Borowski wrote:
> Another thing is, Arora is dead upstream and no one stepped in to revive it. 

shirish's mai to debian-devel
()
reminded me that xxxterm seems to be a possible replacement for Arora
which ssems to be also quite lean for a WebKit based browser.

BTW: dillo 3 is now in the NEW queue.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20110724102015.gr29...@sym.noone.org

Re: Writing to /etc/ from a "privileged" UI

[Osamu Aoki]

On Wed, May 11, 2011 at 10:15:48PM +0100, Dominic Hargreaves wrote:
> On Wed, May 11, 2011 at 10:54:16PM +0200, Adam Borowski wrote:
> > On Wed, May 11, 2011 at 10:05:40PM +0200, Frank Küster wrote:
> > > Not at the same time, but someone might allow a user of a laptop to
> > > access their WLAN, but neither accept that an other user of the laptop
> > > should be able to use the same network without asking, nor that the keys
> > > be written in a system-wide configuration file.
> > 
> > Sorry but if you alternate physical possession of a laptop with someone whom
> > you suspect of being hostile, no files are secure as long as they're stored
> > on that laptop.
> 
> This is not necessarily the case if a per-user encrypted filestore,
> such as ecryptfs, is in use (where a user may be unlocking access to
> their home directory at the same time as logging in, via a pam hook).

Ecryptfs is good at protecting user data in case of stolen hardware but
in case of alternate physical possession, it is not much of protection.
All it requires is to set up one daemon running as root to copy your
data with different permission automatically after you log-in to your
account and hand it back to you.  Not even kernel trick is needed for
this and very simple.

But if you are protecting your kids from accessing uncontrolled network,
may be simple solution such as making some configuration file unreadable
by other normal user may be sufficient.  Adding some logging od your
kids account activity may be another good practice.

Osamu


--
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/20110724063713.ga19...@debian.org