RT for crt.cs.wisc.edu
RT for crt.cs.wisc.edu
Comments about this user:
No comment entered about this user This user's 10 highest priority tickets:
|
|
| # | Wed Jun 25 17:50:46 2008 | ASim@lbl.gov - Ticket created | [Reply] | |||||||||||
Hi Alain, bestman, srm-client-2 and srm-tester-2 version 2.2.0.11 are ready to download from http://datagrid.lbl.gov/bestman. It updates few bug fixes and some new features. http://datagrid.lbl.gov/bestman/pkg/bestman-2.2.0.11.tar.gz http://datagrid.lbl.gov/bestman/pkg/srmclient2-2.2.0.11.tar.gz http://datagrid.lbl.gov/bestman/pkg/srmtester2-2.2.0.11.tar.gz As we discussed on sudo, this version contains the sudo capability for accessing local user data on behalf of the user, and by default I have it disabled. It is desirable to print out after VDT-install about thisfeature, and have them aware of it. Most of T2/T3 wanted this feature. In case this needs to be enabled, the /etc/sudoers need to be modified as following: Cmnd_Alias SRM_CMD = /bin/rm, /bin/mkdir, /bin/rmdir, /bin/mv, /bin/ls Runas_Alias SRM_USR = ALL, !root daemon ALL=(SRM_USR) NOPASSWD: SRM_CMD for the "daemon" running bestman server. And, conf/bestman.rc needs to be modified for the following line: accessFileSysViaSudo=true thanks, and let us know if you have any questions... -- -- Alex asim at lbl dot gov |
||||||||||||||
| # | Wed Jun 25 17:55:19 2008 | kronenfe - Priority changed from (no value) to '3' | ||
| # | Wed Jun 25 17:55:20 2008 | kronenfe - Taken | ||
| # | Wed Jun 25 18:37:03 2008 | kronenfe - Correspondence added | [Reply] | |
|
Hi Alex, Just to confirm, the sudo capability should be disabled by default on an install? We'll put a message in post-install/README telling users how to enable it. > [ASim@lbl.gov - Wed Jun 25 17:50:46 2008]: > > Hi Alain, > > bestman, srm-client-2 and srm-tester-2 version 2.2.0.11 are ready to > download > from http://datagrid.lbl.gov/bestman. It updates few bug fixes and > some new features. > > > http://datagrid.lbl.gov/bestman/pkg/bestman-2.2.0.11.tar.gz > http://datagrid.lbl.gov/bestman/pkg/srmclient2-2.2.0.11.tar.gz > http://datagrid.lbl.gov/bestman/pkg/srmtester2-2.2.0.11.tar.gz > > As we discussed on sudo, this version contains the sudo capability for > accessing local user data on behalf of the user, and by default I have > it disabled. It is desirable to print out after VDT-install about > thisfeature, and have them aware of it. Most of T2/T3 wanted this > feature. > > In case this needs to be enabled, the /etc/sudoers need to be modified > as following: > > Cmnd_Alias SRM_CMD = /bin/rm, /bin/mkdir, /bin/rmdir, /bin/mv, /bin/ls > Runas_Alias SRM_USR = ALL, !root > daemon ALL=(SRM_USR) NOPASSWD: SRM_CMD > > for the "daemon" running bestman server. > > And, conf/bestman.rc needs to be modified for the following line: > > accessFileSysViaSudo=true > > thanks, and let us know if you have any questions... > > > |
||||
| # | Wed Jun 25 18:37:04 2008 | RT_System - Status changed from 'new' to 'open' | ||
| # | Wed Jun 25 18:51:04 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||
Hi Scot, if you do not put any related options to the "configure", it'll have it "false" by default. I think that would be safer for now, and when people want to enable it, have them follow post-install/README to update sudoers and bestman.rc. thanks -- Alex asim at lbl dot gov On 6/25/08 4:37 PM, Scot Kronenfeld via RT wrote: > Hi Alex, > Just to confirm, the sudo capability should be disabled by default on an > install? We'll put a message in post-install/README telling users how > to enable it. > > > >> [ASim@lbl.gov - Wed Jun 25 17:50:46 2008]: >>> >> Hi Alain, >> >> bestman, srm-client-2 and srm-tester-2 version 2.2.0.11 are ready to >> download >> from http://datagrid.lbl.gov/bestman. It updates few bug fixes and >> some new features. >> >> >> http://datagrid.lbl.gov/bestman/pkg/bestman-2.2.0.11.tar.gz >> http://datagrid.lbl.gov/bestman/pkg/srmclient2-2.2.0.11.tar.gz >> http://datagrid.lbl.gov/bestman/pkg/srmtester2-2.2.0.11.tar.gz >> >> As we discussed on sudo, this version contains the sudo capability for >> accessing local user data on behalf of the user, and by default I have >> it disabled. It is desirable to print out after VDT-install about >> thisfeature, and have them aware of it. Most of T2/T3 wanted this >> feature. >> >> In case this needs to be enabled, the /etc/sudoers need to be modified >> as following: >> >> Cmnd_Alias SRM_CMD = /bin/rm, /bin/mkdir, /bin/rmdir, /bin/mv, /bin/ls >> Runas_Alias SRM_USR = ALL, !root >> daemon ALL=(SRM_USR) NOPASSWD: SRM_CMD >> >> for the "daemon" running bestman server. >> >> And, conf/bestman.rc needs to be modified for the following line: >> >> accessFileSysViaSudo=true >> >> thanks, and let us know if you have any questions... >> >> >> >> > > |
||||||||||||
| # | Wed Jun 25 19:51:02 2008 | roy - Correspondence added | [Reply] | |||||||||
If we want a succinct sentence to tell them why them might want to enable it, could you suggest one? -alain On Jun 25, 2008, at 6:51 PM, ASim@lbl.gov via RT wrote: > http://vdt.cs.wisc.edu/rt/Ticket/Display.html?id=3631 > > Hi Scot, > > if you do not put any related options to the "configure", it'll have > it > "false" by default. > I think that would be safer for now, and when people want to enable > it, > have them follow post-install/README to update sudoers and bestman.rc. > > thanks > > -- Alex > asim at lbl dot gov |
||||||||||||
| # | Thu Jun 26 09:33:57 2008 | kronenfe - Comments added | [Reply] | |||||||
Commit comment: Upgraded Bestman, SRM-Client-LBNL, and SRM-Tester-LBNL from 2.2.0.10 to 2.2.0.11 Changed files: U vdt/branches/vdt-1.10.1/defs To generate a diff: svn diff -c 7873 file:///p/vdt/workspace/svn |
||||||||||
| # | Thu Jun 26 12:10:44 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||
good point... I'll come up with one today,. thanks -- Alex asim at lbl dot gov On 6/25/08 5:51 PM, Alain Roy via RT wrote: > If we want a succinct sentence to tell them why them might want to > enable it, could you suggest one? > > -alain > > On Jun 25, 2008, at 6:51 PM, ASim@lbl.gov via RT wrote: > > >> http://vdt.cs.wisc.edu/rt/Ticket/Display.html?id=3631 >>> >> Hi Scot, >> >> if you do not put any related options to the "configure", it'll have >> it >> "false" by default. >> I think that would be safer for now, and when people want to enable >> it, >> have them follow post-install/README to update sudoers and bestman.rc. >> >> thanks >> >> -- Alex >> asim at lbl dot gov >> > > > |
||||||||||||
| # | Thu Jun 26 14:35:39 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||
How about this? ###################################################### BeStMan provides an access to the user managed storage spaces through SRM interface. For consistent permission issues, BeStMan uses sudo to access those user managed directories and files. To enable this feature, /etc/sudoers and bestman/conf/bestman.rc files need to be modified as following. When bestman runs under "daemon" account as used in VDT installation, Cmnd_Alias SRM_CMD = /bin/rm, /bin/mkdir, /bin/rmdir, /bin/mv, /bin/ls Runas_Alias SRM_USR = ALL, !root daemon ALL=(SRM_USR) NOPASSWD: SRM_CMD the above entries are needed in /etc/sudoers file. Also, bestman/conf/bestman.rc needs the update on following entry : accessFileSysViaSudo=true ######################################################## -- Alex asim at lbl dot gov On 6/25/08 5:51 PM, Alain Roy via RT wrote: > If we want a succinct sentence to tell them why them might want to > enable it, could you suggest one? > > -alain > > On Jun 25, 2008, at 6:51 PM, ASim@lbl.gov via RT wrote: > > >> http://vdt.cs.wisc.edu/rt/Ticket/Display.html?id=3631 >>> >> Hi Scot, >> >> if you do not put any related options to the "configure", it'll have >> it >> "false" by default. >> I think that would be safer for now, and when people want to enable >> it, >> have them follow post-install/README to update sudoers and bestman.rc. >> >> thanks >> >> -- Alex >> asim at lbl dot gov >> > > > |
||||||||||||
| # | Thu Jun 26 15:00:32 2008 | kronenfe - Comments added | [Reply] | |||||||
Commit comment: Added a post-install/README message about enabling usage of sudo for bestman. Changed files: U vdt/branches/vdt-1.10.1/Configure-Bestman/vdt/setup/configure_bestman To generate a diff: svn diff -c 7875 file:///p/vdt/workspace/svn |
||||||||||
| # | Thu Jun 26 15:10:42 2008 | roy - Correspondence added | [Reply] | |||||||||
On Jun 26, 2008, at 2:35 PM, ASim@lbl.gov via RT wrote: > How about this? > > ###################################################### > BeStMan provides an access to the user managed storage spaces through> SRM interface. For consistent permission issues, BeStMan uses sudo to > access those user managed directories and files. To enable this > feature, > /etc/sudoers and bestman/conf/bestman.rc files need to be modified as > following. When bestman runs under "daemon" account as used in VDT > installation, That's close, but what does "consistent permission issues" mean? I have no idea. > Cmnd_Alias SRM_CMD = /bin/rm, /bin/mkdir, /bin/rmdir, /bin/mv, /bin/ls > Runas_Alias SRM_USR = ALL, !root > daemon ALL=(SRM_USR) NOPASSWD: SRM_CMD Will people feel comfortable with this, since it affects all programs run by daemon? Daemon will be allowed to do "sudo rm -rf /*"? -alain |
||||||||||||
| # | Thu Jun 26 15:41:28 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||
On 6/26/08 1:10 PM, Alain Roy via RT wrote: > On Jun 26, 2008, at 2:35 PM, ASim@lbl.gov via RT wrote: > >> How about this? >>> >> ###################################################### >> BeStMan provides an access to the user managed storage spaces through>> SRM interface. For consistent permission issues, BeStMan uses sudo to >> access those user managed directories and files. To enable this >> feature, >> /etc/sudoers and bestman/conf/bestman.rc files need to be modified as >> following. When bestman runs under "daemon" account as used in VDT >> installation, >> > That's close, but what does "consistent permission issues" mean? I > have no idea. > like home directory... user has the ownership of dirs and files. when bestman process owner (daemon) accesses those files/dirs, the ownership changes or prohibits the access... is there any other words to describe it? that'll be great.... > >> Cmnd_Alias SRM_CMD = /bin/rm, /bin/mkdir, /bin/rmdir, /bin/mv, /bin/ls >>> Runas_Alias SRM_USR = ALL, !root >> daemon ALL=(SRM_USR) NOPASSWD: SRM_CMD >> > Will people feel comfortable with this, since it affects all programs > run by daemon? Daemon will be allowed to do "sudo rm -rf /*"? > > If it's bestman access, bestman does not allow access to /, /etc, /var by default, and more can be configured. This sudo is through the user account, and it's the same as what users do on the interactive node. if they have permission, they can remove. otherwise, they can't. If a direct execution of sudo as "daemon" account is possible on the node, yes, but it's non-root access, so root files/dirs can't be removed. --Alex |
||||||||||||
| # | Thu Jun 26 17:31:30 2008 | roy - Correspondence added | [Reply] | |||||||||
On Jun 26, 2008, at 3:41 PM, ASim@lbl.gov via RT wrote: >>> How about this? >>>>> >>> ###################################################### >>> BeStMan provides an access to the user managed storage spaces >>> through >>> SRM interface. For consistent permission issues, BeStMan uses sudo >>> to >>> access those user managed directories and files. To enable this >>> feature, >>> /etc/sudoers and bestman/conf/bestman.rc files need to be modified >>> as >>> following. When bestman runs under "daemon" account as used in VDT >>> installation, >>> >> That's close, but what does "consistent permission issues" mean? I >> have no idea. >> > like home directory... user has the ownership of dirs and files. when > bestman process owner (daemon) accesses those files/dirs, the > ownership > changes or prohibits the access... is there any other words to > describe > it? that'll be great.... I'm sorry, I'm not understanding. I might be extra dense today. Are these for pre-existing files that Bestman accesses, or are these files that are put in via Bestman? I would think that if Bestman put them in, there wouldn't be a problem. >>> Cmnd_Alias SRM_CMD = /bin/rm, /bin/mkdir, /bin/rmdir, /bin/mv, / >>>>> bin/ls >>> Runas_Alias SRM_USR = ALL, !root >>> daemon ALL=(SRM_USR) NOPASSWD: SRM_CMD >>> >> Will people feel comfortable with this, since it affects all programs >> run by daemon? Daemon will be allowed to do "sudo rm -rf /*"? >> >> > If it's bestman access, bestman does not allow access to /, /etc, /var > by default, and more can be configured. This sudo is through the user > account, and it's the same as what users do on the interactive node. > if > they have permission, they can remove. otherwise, they can't. > > If a direct execution of sudo as "daemon" account is possible on the > node, yes, but it's non-root access, so root files/dirs can't be > removed. My point is that other software runs as the daemon user. In the VDT, we run a lot of things as daemon, and there are various Linux daemons that run as the daemon user. So all of these processes have sudo access to remove the entire contents of the file system. If there is a security flaw in any one of them (Bestman or otherwise), it could be used to do this. The daemon user is generally restricted so that daemons don't have such permission and security flaws aren't so harmful. Does this un-do the standard security on a system? Thanks, -alain |
||||||||||||
| # | Thu Jun 26 18:10:36 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||
On 6/26/08 3:31 PM, Alain Roy via RT wrote: > On Jun 26, 2008, at 3:41 PM, ASim@lbl.gov via RT wrote: > >>>> How about this? >>> That's close, but what does "consistent permission issues" mean? I>>>> >>>> ###################################################### >>>> BeStMan provides an access to the user managed storage spaces >>>> through >>>> SRM interface. For consistent permission issues, BeStMan uses sudo >>>> to >>>> access those user managed directories and files. To enable this >>>> feature, >>>> /etc/sudoers and bestman/conf/bestman.rc files need to be modified >>>> as >>>> following. When bestman runs under "daemon" account as used in VDT >>>> installation, >>>> >>>> >>> have no idea. >>> >>> >> bestman process owner (daemon) accesses those files/dirs, the >> ownership >> changes or prohibits the access... is there any other words to >> describe >> it? that'll be great.... >> > I'm sorry, I'm not understanding. I might be extra dense today. Are > these for pre-existing files that Bestman accesses, or are these files > that are put in via Bestman? I would think that if Bestman put them > in, there wouldn't be a problem. > > those are files that exists already and bestman accesses for the user or that user wants create through bestman. bestman by itself without sudo cannot create or access them because e.g. they are in user's home directory owned by the user's login (other than bestman process owner). >>>> Cmnd_Alias SRM_CMD = /bin/rm, /bin/mkdir, /bin/rmdir, /bin/mv, / >>> Will people feel comfortable with this, since it affects all programs>>>> bin/ls >>>> Runas_Alias SRM_USR = ALL, !root >>>> daemon ALL=(SRM_USR) NOPASSWD: SRM_CMD >>>> >>>> >>> run by daemon? Daemon will be allowed to do "sudo rm -rf /*"? >>> >>> >>> >> by default, and more can be configured. This sudo is through the user >> account, and it's the same as what users do on the interactive node. >> if >> they have permission, they can remove. otherwise, they can't. >> >> If a direct execution of sudo as "daemon" account is possible on the >> node, yes, but it's non-root access, so root files/dirs can't be >> removed. >> > My point is that other software runs as the daemon user. In the VDT, > we run a lot of things as daemon, and there are various Linux daemons > that run as the daemon user. So all of these processes have sudo > access to remove the entire contents of the file system. If there is a > security flaw in any one of them (Bestman or otherwise), it could be > used to do this. The daemon user is generally restricted so that > daemons don't have such permission and security flaws aren't so > harmful. Does this un-do the standard security on a system? > in that case, it's advisable to use something other than "daemon", like "srm". I can only speak for bestman, and we do everything we can to prevent all misbehaves. this sudo access through bestman will give users the ability to do those 5 commands as they can do locally as long as permission is allowed for the user. (and by the way, we don't take "*" as SURL.) thanks --Alex |
||||||||||||
| # | Thu Jun 26 18:30:40 2008 | roy - Correspondence added | [Reply] | |||||||||
On Jun 26, 2008, at 6:10 PM, ASim@lbl.gov via RT wrote: > those are files that exists already and bestman accesses for the user > or that user wants create through bestman. > bestman by itself without sudo cannot create or access them because > e.g. > they are in user's home directory owned by the user's login (other > than > bestman process owner). Ah, I understand. And that's something that Bestman couldn't easily do before, right? Gotcha. So how about this for a message? BeStMan provides access to the user managed storage spaces through an SRM interface. If you want to access files that might be created outside of Bestman, Bestman needs to use sudo to access these files. To enable Bestman to use sudo and access these files, /etc/sudoers and bestman/conf/bestman.rc files need to be modified as following. When bestman runs under "daemon" account as used in VDT installation, [etc...] Does that express it properly? -alain |
||||||||||||
| # | Thu Jun 26 18:41:25 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||
-- Alex asim at lbl dot gov On 6/26/08 4:30 PM, Alain Roy via RT wrote: > On Jun 26, 2008, at 6:10 PM, ASim@lbl.gov via RT wrote: > >> those are files that exists already and bestman accesses for the user >>> or that user wants create through bestman. >> bestman by itself without sudo cannot create or access them because >> e.g. >> they are in user's home directory owned by the user's login (other >> than >> bestman process owner). >> > Ah, I understand. And that's something that Bestman couldn't easily do > before, right? Gotcha. > alright.... yes.... we couldn't do "write", "mkdir/rmdir" and "remove" specially. > So how about this for a message? > > BeStMan provides access to the user managed storage spaces through an > SRM interface. If you want to access files that might be created > outside of Bestman, Bestman needs to use sudo to access these files. > To enable Bestman to use sudo and access these files, /etc/sudoers and > bestman/conf/bestman.rc files need to be modified as following. When > bestman runs under "daemon" account as used in VDT installation, > [etc...] > > Does that express it properly? > I changed "outside of BeStMan," to "outside of BeStMan managed cache," as following: BeStMan provides access to the user managed storage spaces through an SRM interface. If you want to access files that might be created outside of BeStMan managed cache, BesStMan needs to use sudo to access these files. To enable BeStMan to use sudo and access these files, /etc/sudoers and bestman/conf/bestman.rc files need to be modified as following. When bestman runs under "daemon" account as used in VDT installation, ... sounds good. thanks --Alex |
||||||||||||
| # | Thu Jun 26 19:41:19 2008 | roy - Correspondence added | [Reply] | |||||||||
On Jun 26, 2008, at 6:41 PM, ASim@lbl.gov via RT wrote: > I changed "outside of BeStMan," to "outside of BeStMan managed cache," > as following: > > BeStMan provides access to the user managed storage spaces through an > SRM interface. If you want to access files that might be created > outside of BeStMan managed cache, BesStMan needs to use sudo to > access these files. To enable BeStMan to use sudo and access these > files, /etc/sudoers and bestman/conf/bestman.rc files need to be > modified as following. When bestman runs under "daemon" account as > used in VDT installation, ... Good, thanks for your patience working this out. Scot--I assume you can put this message in? Thanks, -alain |
||||||||||||
| # | Thu Jun 26 22:00:48 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||
excellent... when is the next release? and is the command still the same as pacman -get http://vdt.cs.wisc.edu/vdt_1101_cache:Bestman except the vdt version number (whatever it'll be)? thanks a lot.... -- Alex asim at lbl dot gov On 6/26/08 5:41 PM, Alain Roy via RT wrote: > On Jun 26, 2008, at 6:41 PM, ASim@lbl.gov via RT wrote: > >> I changed "outside of BeStMan," to "outside of BeStMan managed cache," >>> as following: >> >> BeStMan provides access to the user managed storage spaces through an >> SRM interface. If you want to access files that might be created >> outside of BeStMan managed cache, BesStMan needs to use sudo to >> access these files. To enable BeStMan to use sudo and access these >> files, /etc/sudoers and bestman/conf/bestman.rc files need to be >> modified as following. When bestman runs under "daemon" account as >> used in VDT installation, ... >> > Good, thanks for your patience working this out. > > Scot--I assume you can put this message in? > > Thanks, > -alain > > > |
||||||||||||
| # | Thu Jun 26 23:56:30 2008 | roy - Correspondence added | [Reply] | |||||||||
I'm not sure when the release is. Some time next week, probably. That will be the place that it will be, yes. Right now, it's in a test cache: pacman -get http://vdt.cs.wisc.edu/vdt_11099_cache:Bestman Scot's doing the work. I think it's mostly done, though I don't suppose it has the updated text yet. On Jun 26, 2008, at 10:00 PM, ASim@lbl.gov via RT wrote: > http://vdt.cs.wisc.edu/rt/Ticket/Display.html?id=3631 > > excellent... when is the next release? > and is the command still the same as > pacman -get http://vdt.cs.wisc.edu/vdt_1101_cache:Bestman > except the vdt version number (whatever it'll be)? > thanks a lot.... |
||||||||||||
| # | Fri Jun 27 01:26:30 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||
Great. thanks -- Alex asim at lbl dot gov ----------------------------------- sent from at&t tilt -----Original Message----- From: Alain Roy via RT <vdt-support@OPENSCIENCEGRID.ORG> Sent: Thursday, June 26, 2008 9:56 PM To: ASim@lbl.gov Subject: Re: [vdt-support #3631] bestman pkg version 2.2.0.11 I'm not sure when the release is. Some time next week, probably. That will be the place that it will be, yes. Right now, it's in a test cache: pacman -get http://vdt.cs.wisc.edu/vdt_11099_cache:Bestman Scot's doing the work. I think it's mostly done, though I don't suppose it has the updated text yet. On Jun 26, 2008, at 10:00 PM, ASim@lbl.gov via RT wrote: > http://vdt.cs.wisc.edu/rt/Ticket/Display.html?id=3631 > > excellent... when is the next release? > and is the command still the same as > pacman -get http://vdt.cs.wisc.edu/vdt_1101_cache:Bestman > except the vdt version number (whatever it'll be)? > thanks a lot.... -- View ticket at <http://vdt.cs.wisc.edu/rt/Ticket/Display.html?user=guest&pass=guest&id=3631> VDT Support, vdt-support@ivdgl.org |
||||||||||||
| # | Wed Jul 02 15:50:10 2008 | kronenfe - Comments added | [Reply] | |||||||
Commit comment: Clarified post-install/README message about Bestman's sudo feature. Changed files: U vdt/branches/vdt-1.10.1/Configure-Bestman/vdt/setup/configure_bestman To generate a diff: svn diff -c 7878 file:///p/vdt/workspace/svn |
||||||||||
| # | Thu Jul 10 11:49:00 2008 | kronenfe - Status changed from 'open' to 'resolved' | ||
| # | Thu Jul 10 11:49:15 2008 | kronenfe - Fix scheduled CUR added | ||
| # | Thu Jul 10 11:49:15 2008 | kronenfe - Fixed in 1.10.1e added | ||
Time to display: 3.207415
»|« RT 3.8.2 Copyright 1996-2008 Best Practical Solutions, LLC.
