I have read the posts about trying to deal with an untrusted root. I
know that there is no point in even trying. That's not my issue. My
issue is that sometimes I accidentally commit as root and files get
changed to root ownership blocking normal access to the repository.
All I want is something
On Wed, Aug 27, 2014 at 6:36 AM, D'Arcy J.M. Cain wrote:
> I have read the posts about trying to deal with an untrusted root. I
> know that there is no point in even trying. That's not my issue. My
> issue is that sometimes I accidentally commit as root and files get
> changed to root ownership
On Wed, Aug 27, 2014 at 07:49:30AM -0500, Les Mikesell wrote:
> On Wed, Aug 27, 2014 at 6:36 AM, D'Arcy J.M. Cain wrote:
> > I have read the posts about trying to deal with an untrusted root. I
> > know that there is no point in even trying. That's not my issue. My
> > issue is that sometimes I
On 08/27/2014 01:49 PM, Les Mikesell wrote:
It's basically a bad idea to usefile:// access at all for anything
that might be used under multiple user ids. Maybe even for a single
user...
Well, that sucks. If file:// is not to be used then what are the
available options to those who only nee
On Wed, Aug 27, 2014 at 9:34 AM, Zé wrote:
> On 08/27/2014 01:49 PM, Les Mikesell wrote:
>>
>> It's basically a bad idea to usefile:// access at all for anything
>>
>> that might be used under multiple user ids. Maybe even for a single
>> user...
>
>
> Well, that sucks. If file:// is not to be
On 08/27/2014 03:53 PM, Les Mikesell wrote:
It's not that you can't use it, just that it can't protect you from
the things that can happen through direct file system access. Like
accidentally deleting the whole repo or changing ownership or
permissions.
I don't see your point. There's also a
On Wed, 27 Aug 2014 16:08:14 +, Zé wrote:
...
>
> I don't see your point. There's also a likelihood that those accidents
> can happen on a remote server.
The difference being that anybody can accidentally do a rm -rf on the
part after the file - anybody who can work with the repo.
In a ser
On Wed, Aug 27, 2014 at 11:15 AM, Andreas Krey wrote:
> On Wed, 27 Aug 2014 16:08:14 +, Zé wrote:
> ...
>>
>> I don't see your point. There's also a likelihood that those accidents
>> can happen on a remote server.
>
> The difference being that anybody can accidentally do a rm -rf on the
> pa
On 08/27/2014 04:15 PM, Andreas Krey wrote:
The difference being that anybody can accidentally do a rm -rf on the
part after the file - anybody who can work with the repo.
(...)
When you have a machine to place thefile:// to, you also have
something to run a server on.
If the machine you p
On Wed, Aug 27, 2014 at 10:08 AM, Zé wrote:
> On 08/27/2014 03:53 PM, Les Mikesell wrote:
>>
>> It's not that you can't use it, just that it can't protect you from
>> the things that can happen through direct file system access. Like
>> accidentally deleting the whole repo or changing ownership o
On Aug 27, 2014, at 10:28 AM, Zé wrote:
>
> Additionally, to those security-concious people, installing servers on your
> workstation just to access local repositories isn't exactly on the top of
> best practices. Don't you agree?
>
> And I hate to repeat myself, but I'll repeat for the third
Zé wrote:
> On 08/27/2014 01:49 PM, Les Mikesell wrote:
>> It's basically a bad idea to usefile:// access at all for anything
>> that might be used under multiple user ids. Maybe even for a single
>> user...
>
> Well, that sucks. If file:// is not to be used then what are the
> available option
At Wed, 27 Aug 2014 16:08:14 +0100 =?UTF-8?B?WsOp?= wrote:
>
> On 08/27/2014 03:53 PM, Les Mikesell wrote:
> > It's not that you can't use it, just that it can't protect you from
> > the things that can happen through direct file system access. Like
> > accidentally deleting the whole repo or c
On Wed, Aug 27, 2014 at 10:28 AM, Zé wrote:
> >
>
> And I hate to repeat myself, but I'll repeat for the third time this
> question: if file:// is not intended to be used, then what are the available
> options for those who need a version control system and can't set up a
> server?
The answer isn
On Aug 27, 2014, at 8:41 AM, Les Mikesell wrote:
> On Wed, Aug 27, 2014 at 10:28 AM, Zé wrote:
>>>
>>
>> And I hate to repeat myself, but I'll repeat for the third time this
>> question: if file:// is not intended to be used, then what are the available
>> options for those who need a version
At Wed, 27 Aug 2014 16:28:46 +0100 =?ISO-8859-1?Q?Z=E9?=
wrote:
>
> On 08/27/2014 04:15 PM, Andreas Krey wrote:
> > The difference being that anybody can accidentally do a rm -rf on the
> > part after the file - anybody who can work with the repo.
>
> (...)
>
> > When you have a machine to pl
On Aug 27, 2014, at 8:28 AM, Zé wrote:
> Additionally, to those security-concious people, installing servers on your
> workstation just to access local repositories isn't exactly on the top of
> best practices. Don't you agree?
>
Not at all. Running a "server" which only answers to calls v
On Aug 27, 2014, at 10:08, Zé wrote:
> On 08/27/2014 03:53 PM, Les Mikesell wrote:
>> It's not that you can't use it, just that it can't protect you from
>> the things that can happen through direct file system access. Like
>> accidentally deleting the whole repo or changing ownership or
>> per
> -Original Message-
> And I hate to repeat myself, but I'll repeat for the third time this
> question: if file:// is not intended to be used, then what are the available
> options for those who need a version control system and can't set up a
> server?
>
> Zé
Does the file server support
On Wed, Aug 27, 2014 at 10:34 AM, Zé wrote:
> On 08/27/2014 01:49 PM, Les Mikesell wrote:
>>
>> It's basically a bad idea to usefile:// access at all for anything
>>
>> that might be used under multiple user ids. Maybe even for a single
>> user...
>
>
> Well, that sucks. If file:// is not to be
On Wed, Aug 27, 2014 at 12:58 PM, Bob Archer wrote:
>> -Original Message-
>> And I hate to repeat myself, but I'll repeat for the third time this
>> question: if file:// is not intended to be used, then what are the available
>> options for those who need a version control system and can't
21 matches
Mail list logo
