Re: [BackupPC-users] restricting cgi users restore to their own files, or how to handle many users.

2007-09-28 Thread Rob Owens

Craig Barratt wrote:
 Ronny writes:
 
 I am taking backup of a directory /home, containing ~1000 users.
 And i want to allow each of the users access to restore his own files.
 But NOT to read/restore files that he normaly would not.

 Example: user1 have a file in /home/user1/private.txt that have 600
 permissions. I dont want user2 to be able to read this thru the backuppc
 cgi.

 i have tested this with a line in hosts that say
 server  0   rootuser1,user2

 and it seams to me that user2 can read all files of the backup, even
 files he normaly would have no access to.

 So how others solve this problem ?
 must you have 1000 lines in hosts, one line for each homedir ?  Or are
 there a different way where i can have backuppc check the orginal
 permissions and deny restore if the user in question dont have the right
 access.
 
 BackupPC doesn't provide a mechanism to have fine-grained
 per-user permissions when browsing backups.  The host file
 users have permissions for the entire host: browsing, editing
 the configuration, starting and canceling backups, etc.
 
 Enforcing permissions is a bit difficult since apache doesn't
 provide the uid and gid - just the username - and the backups
 just contain the client uid/gid.  There is no guarantee that
 user names and uid/gids are common between the server and
 client.
 
 Perhaps we could have a new config variable which forces the
 browse path for non-admin users, eg:
 
 $Conf{CgiUserBrowseChroot} = {
 'user1' = '/home:/user1',
 'user2' = '/home:/user2',
 };
 
 (/home is the share, and /user1 is the path relative to
 that share)
 
 There could also be a wildcard form that allows any user to
 browse their folder:
 
 $Conf{CgiUserBrowseChroot} = {
 '*' = '/home:/*',
 };
 
 One drawback is this host won't appear in the pulldown in
 the navigation bar, since that is based on the hosts file.
 So the user has to navigate to their host by knowing the
 correct URL.
 
 Craig

I would absolutely love to have the cgi interface give appropriate
permissions to users like the original poster is asking for.  Even if it
required LDAP or something.  This is one of the things I really miss
about rsnapshot, which I used prior to BackupPC.

Rsnapshot preserves all permissions and ownership of files.  You can
then export the backup tree via NFS or similar, with read-only
permissions.  Every user can browse that NFS share, subject to their
user and group permissions, and restore their own backups.

Here is a link describing how it's done in rsnapshot.
http://www.rsnapshot.org/howto/1.2/rsnapshot-HOWTO.en.html#restoring_backups
I realize that it's not this easy to do with BackupPC, but I think it's
something worth striving for.

By the way, rsnapshot has some drawbacks compared to BackupPC.  For
instance, there is no file pooling, no web interface, and the backup
tree can be a little confusing for beginners to navigate.

-Rob

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/


Re: [BackupPC-users] restricting cgi users restore to their own files, or how to handle many users.

2007-09-28 Thread Ronny Aasen
On Wed, 2007-09-26 at 04:31 -0700, Craig Barratt wrote:
 Ronny writes:
 
  I am taking backup of a directory /home, containing ~1000 users.
  And i want to allow each of the users access to restore his own files.
  But NOT to read/restore files that he normaly would not.
  
  Example: user1 have a file in /home/user1/private.txt that have 600
  permissions. I dont want user2 to be able to read this thru the backuppc
  cgi.
  
  i have tested this with a line in hosts that say
  server  0   rootuser1,user2
  
  and it seams to me that user2 can read all files of the backup, even
  files he normaly would have no access to.
  
  So how others solve this problem ?
  must you have 1000 lines in hosts, one line for each homedir ?  Or are
  there a different way where i can have backuppc check the orginal
  permissions and deny restore if the user in question dont have the right
  access.
 
 BackupPC doesn't provide a mechanism to have fine-grained
 per-user permissions when browsing backups.  The host file
 users have permissions for the entire host: browsing, editing
 the configuration, starting and canceling backups, etc.
 
 Enforcing permissions is a bit difficult since apache doesn't
 provide the uid and gid - just the username - and the backups
 just contain the client uid/gid.  There is no guarantee that
 user names and uid/gids are common between the server and
 client.

that's not a guarantee, but when you have ldap/sql/nis user-uid
mapping it's quite commonly so. 

I assume one could deny access if the user didn't map to a uid.
mapping a user to the wrong uid would be hard to detect. But it's not
your stock configuration anyway so some prerequisites like common user
database can be expected.

 Perhaps we could have a new config variable which forces the
 browse path for non-admin users, eg:
 
 $Conf{CgiUserBrowseChroot} = {
 'user1' = '/home:/user1',
 'user2' = '/home:/user2',
 };
 
 (/home is the share, and /user1 is the path relative to
 that share)
 
 There could also be a wildcard form that allows any user to
 browse their folder:
 
 $Conf{CgiUserBrowseChroot} = {
 '*' = '/home:/*',
 };
 
 One drawback is this host won't appear in the pulldown in
 the navigation bar, since that is based on the hosts file.
 So the user has to navigate to their host by knowing the
 correct URL.


So there is no way to do this currently. Having 1000 hostlines is not
that big a problem for the user. Since it's the admin that have to live
with a _Lng_ dropdown box. 

would backuppc deal with a hostsfile of ~1000 lines and 1000 files
saying server-user[].pl


-- 
mvh
Ronny Aasen -- 41616155 -- [EMAIL PROTECTED] --
Datapart AS -- 57682100 --  www.datapart-as.no  --



signature.asc
Description: This is a digitally signed message part
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/


Re: [BackupPC-users] restricting cgi users restore to their own files, or how to handle many users.

2007-09-26 Thread Craig Barratt
Ronny writes:

 I am taking backup of a directory /home, containing ~1000 users.
 And i want to allow each of the users access to restore his own files.
 But NOT to read/restore files that he normaly would not.
 
 Example: user1 have a file in /home/user1/private.txt that have 600
 permissions. I dont want user2 to be able to read this thru the backuppc
 cgi.
 
 i have tested this with a line in hosts that say
 server  0   rootuser1,user2
 
 and it seams to me that user2 can read all files of the backup, even
 files he normaly would have no access to.
 
 So how others solve this problem ?
 must you have 1000 lines in hosts, one line for each homedir ?  Or are
 there a different way where i can have backuppc check the orginal
 permissions and deny restore if the user in question dont have the right
 access.

BackupPC doesn't provide a mechanism to have fine-grained
per-user permissions when browsing backups.  The host file
users have permissions for the entire host: browsing, editing
the configuration, starting and canceling backups, etc.

Enforcing permissions is a bit difficult since apache doesn't
provide the uid and gid - just the username - and the backups
just contain the client uid/gid.  There is no guarantee that
user names and uid/gids are common between the server and
client.

Perhaps we could have a new config variable which forces the
browse path for non-admin users, eg:

$Conf{CgiUserBrowseChroot} = {
'user1' = '/home:/user1',
'user2' = '/home:/user2',
};

(/home is the share, and /user1 is the path relative to
that share)

There could also be a wildcard form that allows any user to
browse their folder:

$Conf{CgiUserBrowseChroot} = {
'*' = '/home:/*',
};

One drawback is this host won't appear in the pulldown in
the navigation bar, since that is based on the hosts file.
So the user has to navigate to their host by knowing the
correct URL.

Craig

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/


Re: [BackupPC-users] restricting cgi users restore to their own files, or how to handle many users.

2007-09-26 Thread Ronny Aasen
Sorry about the duplicate post. Trying to use the right address now !


 Ronny writes:
 
  I am taking backup of a directory /home, containing ~1000 users.
  And i want to allow each of the users access to restore his own files.
  But NOT to read/restore files that he normaly would not.
  
  Example: user1 have a file in /home/user1/private.txt that have 600
  permissions. I dont want user2 to be able to read this thru the backuppc
  cgi.
  
  i have tested this with a line in hosts that say
  server  0   rootuser1,user2
  
  and it seams to me that user2 can read all files of the backup, even
  files he normaly would have no access to.
  
  So how others solve this problem ?
  must you have 1000 lines in hosts, one line for each homedir ?  Or are
  there a different way where i can have backuppc check the orginal
  permissions and deny restore if the user in question dont have the right
  access.
 
 BackupPC doesn't provide a mechanism to have fine-grained
 per-user permissions when browsing backups.  The host file
 users have permissions for the entire host: browsing, editing
 the configuration, starting and canceling backups, etc.
 
 Enforcing permissions is a bit difficult since apache doesn't
 provide the uid and gid - just the username - and the backups
 just contain the client uid/gid.  There is no guarantee that
 user names and uid/gids are common between the server and
 client.

that's not a guarantee, but when you have ldap/sql/nis user-uid
mapping it's quite commonly so. 

I assume one could deny access if the user didn't map to a uid.
mapping a user to the wrong uid would be hard to detect. But it's not
your stock configuration anyway so some prerequisites like common user
database can be expected.

 Perhaps we could have a new config variable which forces the
 browse path for non-admin users, eg:
 
 $Conf{CgiUserBrowseChroot} = {
 'user1' = '/home:/user1',
 'user2' = '/home:/user2',
 };
 
 (/home is the share, and /user1 is the path relative to
 that share)
 
 There could also be a wildcard form that allows any user to
 browse their folder:
 
 $Conf{CgiUserBrowseChroot} = {
 '*' = '/home:/*',
 };
 
 One drawback is this host won't appear in the pulldown in
 the navigation bar, since that is based on the hosts file.
 So the user has to navigate to their host by knowing the
 correct URL.


So there is no way to do this currently. Having 1000 hostlines is not
that big a problem for the user. Since it's the admin that have to live
with a _Lng_ dropdown box. 

would backuppc deal with a hostsfile of ~1000 lines and 1000 files
saying server-user[].pl


-- 
mvh
Ronny Aasen -- 41616155 -- [EMAIL PROTECTED] --
Datapart AS -- 57682100 --  www.datapart-as.no  --



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/


Re: [BackupPC-users] restricting cgi users restore to their own files, or how to handle many users.

2007-09-26 Thread Jack Coats
I only ever have seen one backup package that allowed that fine grained
restores. ... SyBack by SyncSort, Inc. on the IBM VM operating system
for CMS users.  

Any user could restore any file they owned or could read to wherever
they had write permissions to.

That would be a 'killer enhancement to BackupPC!

On Wed, 2007-09-26 at 04:31 -0700, Craig Barratt wrote:
 Ronny writes:
 
  I am taking backup of a directory /home, containing ~1000 users.
  And i want to allow each of the users access to restore his own files.
  But NOT to read/restore files that he normaly would not.
  
  Example: user1 have a file in /home/user1/private.txt that have 600
  permissions. I dont want user2 to be able to read this thru the backuppc
  cgi.
  
  i have tested this with a line in hosts that say
  server  0   rootuser1,user2
  
  and it seams to me that user2 can read all files of the backup, even
  files he normaly would have no access to.
  
  So how others solve this problem ?
  must you have 1000 lines in hosts, one line for each homedir ?  Or are
  there a different way where i can have backuppc check the orginal
  permissions and deny restore if the user in question dont have the right
  access.
 
 BackupPC doesn't provide a mechanism to have fine-grained
 per-user permissions when browsing backups.  The host file
 users have permissions for the entire host: browsing, editing
 the configuration, starting and canceling backups, etc.
 
 Enforcing permissions is a bit difficult since apache doesn't
 provide the uid and gid - just the username - and the backups
 just contain the client uid/gid.  There is no guarantee that
 user names and uid/gids are common between the server and
 client.
 
 Perhaps we could have a new config variable which forces the
 browse path for non-admin users, eg:
 
 $Conf{CgiUserBrowseChroot} = {
 'user1' = '/home:/user1',
 'user2' = '/home:/user2',
 };
 
 (/home is the share, and /user1 is the path relative to
 that share)
 
 There could also be a wildcard form that allows any user to
 browse their folder:
 
 $Conf{CgiUserBrowseChroot} = {
 '*' = '/home:/*',
 };
 
 One drawback is this host won't appear in the pulldown in
 the navigation bar, since that is based on the hosts file.
 So the user has to navigate to their host by knowing the
 correct URL.
 
 Craig
 
 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2005.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 BackupPC-users mailing list
 BackupPC-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/backuppc-users
 http://backuppc.sourceforge.net/


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/


[BackupPC-users] restricting cgi users restore to their own files, or how to handle many users.

2007-09-25 Thread Ronny Aasen
Hello.

I have installed backuppc + apache2 ldap_auth on debian etch and it's
working great. 

Now i have one challenge that i have not been able to find a solution
for in the docs or mailinglist archives. If it's been answered allready
I would very much like a url.

I am taking backup of a directory /home, containing ~1000 users. 
And i want to allow each of the users access to restore his own files. 
But NOT to read/restore files that he normaly would not. 

Example: user1 have a file in /home/user1/private.txt that have 600
permissions. I dont want user2 to be able to read this thru the backuppc
cgi. 

i have tested this with a line in hosts that say
server  0   rootuser1,user2

and it seams to me that user2 can read all files of the backup, even
files he normaly would have no access to.

So how others solve this problem ? 
must you have 1000 lines in hosts, one line for each homedir ?  Or are
there a different way where i can have backuppc check the orginal
permissions and deny restore if the user in question dont have the right
access.

Kind regards
-- 
mvh
Ronny Aasen -- 41616155 -- [EMAIL PROTECTED] --
Datapart AS -- 57682100 --  www.datapart-as.no  --



signature.asc
Description: This is a digitally signed message part
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/