* Andreas Barth [2012-05-13 11:06 +0200]:
> * Russ Allbery (rra@debian.org) [120512 23:06]:
> > Charles Plessy <plessy@debian.org> writes:
> >
> > > Unless we expect that two different binary packages that can be
> > > co-installed will distribute the same directory under different
> > > ownership or permissions for a good reason, why not simply let dpkg
> > > apply ownership and permissions found in data.tar.{gz|bz2|xz},
> >
> > Usually because the UID is dynamically assigned and the user is created in
> > the postinst, so there's no way for dpkg do do this at unpack.
> >
> > You would need to apply permissions by name, not UID/GID, and you would
> > need to create all users in preinst prior to unpack, which would require
> > Pre-Depends on adduser with all the complexity that entails. I haven't
> > thought through that path to see if there are any other problems.
>
> Wouldn't it be sensible to describe which user(s) a programm needs as
> well not by "adduser $user" but in a more abstract syntax

I agree.

> and let dpkg handle all of that?

This doesn't look like a task that should be done by dpkg itself;
instead debhelper or dpkg-maintscript-helper could be used.


Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120513101924.GA19675@furrball.stateful.de">http://lists.debian.org/20120513101924.GA19675@furrball.stateful.de

Hi,

On 12/05/12 12:23, Peter Palfrader wrote:
> This may not be entirely trivial to solve. find | xargs constructs at best
> mitigate this to a race. While chown does have a --no-derefence flag, this
> does not protect us in the case of hardlinks. chmod has no such flag, and it'd
> useful only for symlinks anyway. Neither tool has a --only-if-link-count-is-one
> flag.

>From find(1):
-links n
File has n links.

So I guess this specific problem could theoretically be solved this way.
However, I'm actually also for a more general solution, as being
discussed for dpkg or at least debhelper.


Cheers

--
Leo "costela" Antunes
[insert a witty retort here]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: joogrv$go4$1@dough.gmane.org">http://lists.debian.org/joogrv$go4$1@dough.gmane.org

Hi,
Is there anybody familar with Solaris IPS manifests [1]?
They are terrible and unflexible, but allow describing users, permissions etc.
I thinks post/pre/install/remove scripts are create advantage, cause

they allow do dirty things *iff* needed.
[1]Â*http://www.oracle.com/technetwork/server-storage/solaris11/technologies/ips-323421.html

On Sun, 13 May 2012, Leo "costela" Antunes wrote:

> Hi,
>
> On 12/05/12 12:23, Peter Palfrader wrote:
> > This may not be entirely trivial to solve. find | xargs constructs at best
> > mitigate this to a race. While chown does have a --no-derefence flag, this
> > does not protect us in the case of hardlinks. chmod has no such flag, and it'd
> > useful only for symlinks anyway. Neither tool has a --only-if-link-count-is-one
> > flag.
>
> >From find(1):
> -links n
> File has n links.
>
> So I guess this specific problem could theoretically be solved this way.
> However, I'm actually also for a more general solution, as being
> discussed for dpkg or at least debhelper.
This creates just a race condition.

Alex



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120513154944.GC19213@smithers.snow-crash.org">http://lists.debian.org/20120513154944.GC19213@smithers.snow-crash.org

Carsten Hey <carsten@debian.org> writes:
> * Andreas Barth [2012-05-13 11:06 +0200]:
>> * Russ Allbery (rra@debian.org) [120512 23:06]:

>>> Usually because the UID is dynamically assigned and the user is
>>> created in the postinst, so there's no way for dpkg do do this at
>>> unpack.

>>> You would need to apply permissions by name, not UID/GID, and you
>>> would need to create all users in preinst prior to unpack, which would
>>> require Pre-Depends on adduser with all the complexity that entails.
>>> I haven't thought through that path to see if there are any other
>>> problems.

>> Wouldn't it be sensible to describe which user(s) a programm needs as
>> well not by "adduser $user" but in a more abstract syntax

> I agree.

You certainly don't have to convince me of that. *The* biggest thing
that I wish I had time to do for Debian and don't is to write a high-level
declarative language that would implement 80% of the current tasks of
maintainer scripts and allow shell fragments duplicated in N packages
(admittedly often generated by debhelper and therefore consistent and of
high quality, but still requiring a rebuild to change in the rare case of
a bug or requirements change in the debhelper behavior) with a declarative
statement processed by one tool that can patched and updated as needed.

There's a lot less than there used to be thanks to triggers, but still I
bet 80-90% of the maintainer scripts in Debian could be eliminated in
favor of a much simpler, pluggable system.

>> and let dpkg handle all of that?

> This doesn't look like a task that should be done by dpkg itself;
> instead debhelper or dpkg-maintscript-helper could be used.

Agreed. Putting it directly in the dpkg C code doesn't seem like a good
separation of tasks, although it needs to be closely coordinated so that
we can use the dpkg unpack stage to set ownership.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87havkowfl.fsf@windlord.stanford.edu">http://lists.debian.org/87havkowfl.fsf@windlord.stanford.edu

* Russ Allbery (rra@debian.org) [120513 18:52]:
> Carsten Hey <carsten@debian.org> writes:
> > * Andreas Barth [2012-05-13 11:06 +0200]:

> >> and let dpkg handle all of that?
>
> > This doesn't look like a task that should be done by dpkg itself;
> > instead debhelper or dpkg-maintscript-helper could be used.
>
> Agreed. Putting it directly in the dpkg C code doesn't seem like a good
> separation of tasks, although it needs to be closely coordinated so that
> we can use the dpkg unpack stage to set ownership.

"dpkg" doesn't mean dpkg C code, but part of the dpkg ecosystem
(putting it in debhelper is better than nothing but as you pointed out
not the real thing either).


Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120513173658.GV2385@mails.so.argh.org">http://lists.debian.org/20120513173658.GV2385@mails.so.argh.org

Guillem Jover writes ("Re: on the use of chmod/chown in maintainer scripts"):
> On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote:
> > I can't see an equivalent in GNU tar. But BSD tar is available
> > in Debian.
>
> This would imply BSD tar needs to be promoted to the Essential set
> alongside GNU tar, at which point I might as well just use an
> internal tar implementation.

??? Are we talking about unpack ? Because dpkg's unpack code already
has an internal tar implementation. This is necessary to get all the
file write / rename / conffile / etc. functionality to work properly.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20402.18142.743726.664825@chiark.greenend.org.uk"> http://lists.debian.org/20402.18142.743726.664825@chiark.greenend.org.uk

On Tue, May 15, 2012 at 01:06:54PM +0100, Ian Jackson wrote:

|| Guillem Jover writes ("Re: on the use of chmod/chown in maintainer scripts"):
|| > On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote:
|| > > I can't see an equivalent in GNU tar. But BSD tar is available
|| > > in Debian.
|| >
|| > This would imply BSD tar needs to be promoted to the Essential set
|| > alongside GNU tar, at which point I might as well just use an
|| > internal tar implementation.
||
|| ??? Are we talking about unpack ? Because dpkg's unpack code already
|| has an internal tar implementation. This is necessary to get all the
|| file write / rename / conffile / etc. functionality to work properly.

No, this is about packing. Doing packing with dpkg-deb invoking bsdtar
would either make bsdtar essential, or require that dpkg-deb switch to
use whatever tar is available.

Privately, I've succeeded in bypassing dpkg-deb entirely for packing,
using bsdtar for creating tar-archives as well as ar-archives (for
the .deb format). And no more need for a staging directory or for root
privileges to ensure proper ownership for files in the tar-archive.

Ciao. Vincent.
--
Vincent Zweije <vincent@zweije.nl> | "If you're flamed in a group you
<http://www.xs4all.nl/~zweije/> | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] | -- Paul Tomblin on a.s.r.

]] Vincent Zweije

> No, this is about packing. Doing packing with dpkg-deb invoking bsdtar
> would either make bsdtar essential, or require that dpkg-deb switch to
> use whatever tar is available.

Why would it require more than dpkg-dev depending on bsdtar? We have
precedence for packages being ok with not depending on everything they
need for all parts of their functionality.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87txzhikh0.fsf@xoog.err.no">http://lists.debian.org/87txzhikh0.fsf@xoog.err.no

Russ Allbery <rra@debian.org> writes:

> Charles Plessy <plessy@debian.org> writes:
>
>> in some of my packages, I give the ownership on some directories in /var
>> to www-data without checking that the www-data group exists, but I guess
>> it is acceptable because it is globally allocated by base-passwd.
>
> Right.
>
>> Dpkg will not update permissions or ownership, but when creating the
>> directory it will apply the ones in the 'data' tar archive. So if there
>> was no package released with wrong settings, I assume this is safe. Or
>> am I simply relying on something undocumented and unwaranteed ?
>
> No, this is fine. But it only works for globally-allocated IDs in
> base-passwd. If you instead need to dynamically generate a system user on
> the fly and then set ownership of files to that user, which is a
> reasonably common case, this is more complex.

Actualy not quite. This fails during bootstrap if base-passwd is not yet
configured.

While base-passwd is essential the /etc/passwd is only created during
postinst and thus not covered by base-passwd being essential. So if you
are essential (or pseudo essential, something essential depends on you)
you have to depend on base-passwd to ensure your postinst is run after
base-passwd is configured.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 878vgsqpc6.fsf@frosties.localnet">http://lists.debian.org/878vgsqpc6.fsf@frosties.localnet