Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client
> In fact, my 'sudo' approach worked so well …
Then, how do you restrict access to certain paths in your setups?
Am 11.02.21 um 01:58 schrieb backu...@kosowsky.org:
> Felix Wolters wrote at about 00:14:37 +0100 on Thursday, February 11, 2021:
> > Jeff,
> >
> > I appreciate your detailled discussion of the topic, and I consider your
> > arguments to be strong.
> >
> > But this …
> >
> > > Finally, while the sudoer code I shared in my previous note was just
> > > aimed at restricting the sudoer power to rsync with specific flags,
> > > I'm pretty sure that it could be easily expanded to
> > > also limit access to only certain files/directories but just extending
> > > the sudoer line to add the paths desired, thereby further restricting
> > > the reach of the sudo command allowed.
> > seems to be the critical point to me. Have your tried that? (I haven’t
> > yet; a quick search at least doesn’t show up manifestations of this
> > approach.)
>
> I'm not sure anyone else has done the detailed specific sudoer approach that I
> use for backuppc so not surprised it's not documented :)
>
> I'm pretty confident the approach will work to restrict files as you
> can verify using 'ps' what the full command line is... Just run 'ps
> aux | grep rsync' when you are running a backup...
>
> In fact, my 'sudo' approach worked so well that I was stumped when
> backuppc stopped working when I upgraded my rsync version and it
> stopped working -- only after much flailing, did I realize that for
> rsync >=3.1.x, two new command line parameters ('xC') were added.
>
> Remember ultimately both approaches are trying to do the same thing by
> restricting the command lines that can be executed -- but as I laid
> out, I think 'normal user escalated with limited sudo' is safer than
> 'root user restricted by combination of ssh option plus perl plus perl
> app of unknown hardness'
>
> I should also point out that there are many subtleties and
> vulnerabilities to the command restriction approach that can introduce
> security issues. For example, you need to protect against shell
> extensions and escapes (as a trivial example, if you allow '&&' then you can
> add an arbitrary command) as well as path changes etc.
>
> The sudo people have had years to weed out such vulnerabilities. I
> have no idea how well rrsync's developer has tested against all types
> of malicious command line manipulations.
>
>
> > > At the end of the day, with rrsync, you are still allowing root
> > >access to ssh and that just doesn't feel right.
> > Well … any time you administrate a remote machine, you gain root access
> > over ssh to it, so this alone is a danger we use to deal with. On the
> > other hand, with the rsync-via-sudoers approach – don’t we open rsync to
> > the full system, so basically an attacker on the currupted server would
> > be able to basically rsync the whole machine to himself? So, at the end
> > of the day, aren’t we trading a potential security vulnerability
> > (rrsync) with a heavy real one (rsync via sudoers)?
> >
> >
> > Am 10.02.21 um 20:59 schrieb backu...@kosowsky.org:
> > > Felix Wolters wrote at about 19:45:49 +0100 on Wednesday, February 10,
> 2021:
> > > > Greg,
> > > >
> > > > Yupp, that’s the principle, especially refer to the paragraph
> > > >
> https://dev-notes.eu/2016/08/secure-rsync-between-servers/#limit-actions-for-this-ssh-connection-to-restricted-rsync
> > > >
> > > > I can recommend it so far.
> > > >
> > > > I may add, that working with a non-privieged user isn’t even necessary
> > > > in many cases, as rrsync is able to restrict access to (1.) a specific
> > > > command (if need be with specific options), (2.) a specific folder,
> and
> > > > (3.) to read only access – but offer full root access and allowing
> rsync
> > > > -a to keep users, groups and permissions. That makes it powerful.
> > >
> > > See my earlier note on my concerns about the relative security of this
> > > method vs. ssh to a restricted remote user plus a well-constructed
> > > sudoer line to elevate only the specific command needed to backup your
> files/directories.
> > >
> > > > The problem here just seems to be that rrsync (on the client to back
> up)
> > > > and rsync-bpc are not compatible, and a patched rrsync will –
> hopefully!
> > > > – be the solution.
> > >
> > >
> > > ___
> > > BackupPC-users mailing list
> > > BackupPC-users@lists.sourceforge.net
> > > List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> > > Wiki:https://github.com/backuppc/backuppc/wiki
> > > Project: https://backuppc.github.io/backuppc/
> >
> >
> > ___
> > BackupPC-users mailing list
> > BackupPC-users@lists.sourceforge.net
> > List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> > Wiki:https://github.com/backuppc/backuppc/wiki
>
Re: [BackupPC-users] Which filesystem for external backup drive?
On 2021-02-11 05:45, G.W. Haywood via BackupPC-users wrote: Hi there, On Thu, 11 Feb 2021, backu...@kosowsky.org wrote: Michael Stowe wrote at about 20:50:45 + on Wednesday, February 10, 2021: > On 2021-02-09 16:34, G.W. Haywood via BackupPC-users wrote: > > Not sure if you misunderstood the question, or didn't follow the link, > or didn't realize it appeared earlier in the thread, but that absolutely > does not qualify as objective data, nor is it particularly accurate. Good point! While people will (and should) compare the pros/cons of different filesystems until the end of time (like vi vs. emacs), it is either naive or highly partisan to think that a well-distributed and accepted filesystem like btrfs is 'unstable'. I don't want to get into a pointless argument but I do feel the need to get the point across. Apparently I haven't yet done a good job of that. The problem seems to be that people don't understand what's meant in this context by the word 'unstable'. Several people seem to think it means "contains faults". It doesn't. It means that it's a moving target. In the case of BTRFS it's been a moving target more or less since its creation, and people at Red Hat were unable to keep up with it for that reason. Which is what I said at the outset, and what is expressed in comments in the link I posted. (This is, incidentally and despite specious argument to the contrary, perfectly objective.) Each of us must draw his own conclusions about how a lack of stability might or might not affect any uses which he might make of any product. In this case, I've drawn mine and I consider the matter now closed. It's not a question of accepting the curiously different-than-usual definition of "unstable," it's looking at the pace of change of btrfs versus other filesystems which are actively maintained and noticing that objectively, the pace of change isn't that different, neither are the reported issues. I note that the comments you linked to are *unsubstantiated opinion*, not objective data, and it's the opinion of a maintenance engineer who, frankly, gets a few things objectively incorrect when expressing this opinion, which even he notes is paraphrased from a source outside Redhat. This doesn't seem to be the official opinion of Redhat, though the maintenance engineer does point out that Redhat has invested heavily in the feature set of other file systems, and pushes Stratis. This is, of course, their prerogative, but the only data in evidence here is that Redhat is supporting Stratis and removing btrfs. Objectively, btrfs has supported COW since it was first considered stable in 2009. This is on the feature list for XFS, which is being actively developed, foundational elements being added in 2016. This fits your definition of "unstable." ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List:https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki:https://github.com/backuppc/backuppc/wiki Project: https://backuppc.github.io/backuppc/
Re: [BackupPC-users] Which filesystem for external backup drive?
Hi there, On Thu, 11 Feb 2021, backu...@kosowsky.org wrote: Michael Stowe wrote at about 20:50:45 + on Wednesday, February 10, 2021: > On 2021-02-09 16:34, G.W. Haywood via BackupPC-users wrote: > > Hi there, > > > > On Tue, 9 Feb 2021, backu...@kosowsky.org wrote: > > > >> G.W. Haywood via BackupPC-users wrote at about 14:26:30 + on > >> Friday, February 5, 2021: > >> > > >> > [Red Hat is] dropping BTRFS because they can't support it in the way they'd > >> > like to for their commercial customers. That's because it's unstable. > >> > It's been said that it's been almost ready for production for about a > >> > decade, and I can't help thinking that it will probably stay that way > >> > until it expires during the heat death of the universe. > >> > >> Any objective data or recent link to such instability. > >> Would be very interested in validating that. > > > > https://access.redhat.com/discussions/3138231 > > Not sure if you misunderstood the question, or didn't follow the link, > or didn't realize it appeared earlier in the thread, but that absolutely > does not qualify as objective data, nor is it particularly accurate. Good point! While people will (and should) compare the pros/cons of different filesystems until the end of time (like vi vs. emacs), it is either naive or highly partisan to think that a well-distributed and accepted filesystem like btrfs is 'unstable'. I don't want to get into a pointless argument but I do feel the need to get the point across. Apparently I haven't yet done a good job of that. The problem seems to be that people don't understand what's meant in this context by the word 'unstable'. Several people seem to think it means "contains faults". It doesn't. It means that it's a moving target. In the case of BTRFS it's been a moving target more or less since its creation, and people at Red Hat were unable to keep up with it for that reason. Which is what I said at the outset, and what is expressed in comments in the link I posted. (This is, incidentally and despite specious argument to the contrary, perfectly objective.) Each of us must draw his own conclusions about how a lack of stability might or might not affect any uses which he might make of any product. In this case, I've drawn mine and I consider the matter now closed. -- 73, Ged. ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List:https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki:https://github.com/backuppc/backuppc/wiki Project: https://backuppc.github.io/backuppc/
