Re: [Gnu-arch-users] Link with permissions

[Robin Farine]

On Thursday 30 September 2004 09.37, address@hidden wrote:

> What I want to say is that the importance of some specific
> meta-data are in the eye of the beholder. This is what lead me to
> think of this generic thing in the first place. Others may care
> about colour, whatever that may be. We unixers just ignore that.

Ah, OK.

> >                   The only thing Arch needs to provide is a
> > hook triggered by commands that alter a project tree, e.g. get,
> > replay, update,.
>
> Yes, and each platform will pick the attributes it cares about
> and do whatever is necessary. A convention about how each
> platform interprets the attributes might help, but won't be
> necessarily part of Arch. Right?

It might even not be necessary to automatically make a choice based 
on the platform. In the case where I maintain my home directory 
under Arch control, I would arrange for my Arch hook script to call 
the appropriate tool with say "home-permissions" in argument to 
apply the UNIX permissions defined in this file of the project 
tree. The tool would just complain and do nothing if it cannot 
parse "home-permission" correctly.

> > It depends on the project. In a lot of projects, we just do not
> > care about the access rights. For projects where they are
> > important, nothing prevents us from having more than one access
> > right description file, each using a syntax adapted to the
> > targeted scheme.
>
> Ah, I see. You propose even a more generic scheme: a mechanism to
> provide a mechanism to deliver extended attributes. I think I
> understand now.

Yes I think we speak roughly about the same thing. Just to be more 
specific, let me give another example. Let us say user bob1 is a 
system administrator and he keeps "/etc" under Arch control. Maybe 
he does not like to run emacs as root or whatever so editing files 
in-place is not an option. Moreover, "/etc/ldap.secret" contains a 
password so this file must be readable by root and bob1 only. His 
"etc" project tree would contain two permission description files. 
One used in his Arch hook, say "permissions.bob1", contains 
something like (* means current uid/gid):

directories       * * 00755         # default for directories
files             * * 00644         # default for files
 ...
 <inventory id for etc/ldap.secret> * * 00600
 ...

The other file, "permissions.root", might look like this:

directories       root root 00755         # default for directories
files             root root 00644         # default for files
 ...
 ?./etc/ldap.secret root root 00600
 ...

and can be used by bob1 to generate a deployment tar file of "etc" 
with the correct access rights for actual "/etc" files (e.g. using 
fakeroot to create the tree, run the tool that apply permissions 
and tar the result).

> Now I think I like your approach. Maybe something is missing,
> though: a set of `good practices' to guide people on how to use
> that. Just to keep different uses from stomping onto each others.

Yeah sure. The first step was for me to know what people think of 
the idea. Whether they think we can simplify tla and imo improve 
its usability (dream: read-only rev libs) by moving the permission 
stuff to an external tool. If it turns out I missed something big 
or that there is no chance in merging the necessary changes into 
mainline, I won't spend days of writing a more formal proposal (2nd 
step) and implement the replacement for UNIX permissions handling 
(3rd step). And as usual, the good practices would follow as the 
4th step, based on other people's feedback :)

Robin