+++ /dev/null
-
-~ is the project directory
-
---------------------------------------------------------------------------------
-most subdirectories are source modules
-
-
---------------------------------------------------------------------------------
-~/tools
-
-Some tools are normally installed on the system. Others are local. Local tools
-are typically standard tools that have been customized for the project or are
-unusual to the project.
-
- ~/tools/bin is for the executables of locally used tools.
- ~/tools/lib is locally used libraries.
- ~/tools/doc is for collected docs on tools
-
-typically a developer will want ~/tools/bin in his search path
-
---------------------------------------------------------------------------------
-~/staged
-
-These are make file build targets. They represent either intermediate or
-finished executables and libraries. When a project has multiple src
-directories and they use each other's work product for the builds, the
-items in the staged area are those that are used by each src directory.
-
-Typically the install target copies material in the staging area to
-system locations.
-
---------------------------------------------------------------------------------
-~/<module>
-
-
-
-
-
+++ /dev/null
-
-
-filename.tag.extension
-
-extension:
- .c for C source
- .cc for C++ source
- .h for C header file
- .hh for C++ header file
- .o an object file
-
-tag:
- .lib. The resulting .o file to be placed in release library and is part of the
- programming interface.
- .aux. The resulting.o file not directly part of the programming interface, but
- it might be called by functions that are.
- .cli. The source file has a main call and is to be relased as part of the command line interface
- .loc. file has a main call to be made into a local uitlity function
-
-We carry the source file tag and extension to the .o file. We do not put tags
-nor extensions on command line executables.
-
-local_common.h should be included in all source files
+++ /dev/null
-1.
-
-For the following makefile, the .PHONY tag is ignored unless there
-is an explicit target with that name. The %:: target is not enough.
-So for expample, if there is an exec directory, the exec target
-caught through the %:: will never fire. The commented lines must
-be added that give an explicit exec target.
-
-
-.PHONY: all version deps lib exec
-all: version deps lib exec
-
-lib:
- $(MAKE) $@
- cp src/tranche.lib.h include/tranche.h
-
-#exec:
-# $(MAKE) $@
-
-%::
- $(MAKE) $@
+++ /dev/null
-
-subu-mk-0
-
- 1. We have to make the subu for step 2 so that we will have subu_uid and subu_gid
- to work with, but we delay this for as long as possible, as the program might
- first bail due to other errors.
-
- 2. Then we add user access via setfacl to masteru's home directory and to
- subu_land, so that we have permissions to make the home directory.
-
- 3. Then as subu we create the home directory. .. I wonder where the system
- gets the umask for this? Perhaps we should create the dir, and then change
- the ownership instead?
-
- 4. Still as subu, we add facls to our directory to give masteru access.
-
-finished, good part is that we never need to move back to root.
-
-setfacl -m u:subu:x masteru
-setfacl -m u:subu:x masteru/subu_land
-setfacl -m d:u:masteru:rwX,u:masteru:rwX subu
-
-
-using luseradd to make the subu is a circular problem because we need to setfacls
-to allow the creating of the home directory inside the masteru/subu_land, but
-to set facls we need the uid from luseradd. So..
- 1. luseradd without creation of a home directory. We can provide the path,
- but can't create it.
- 2. get the uid, and set the facls
- 3. create the home directory
-
-Step 3 is a bit of a problem, because subu's don't have write permission for
-subu_land/
-
-.. or maybe not, luseradd puts users in /home, but those users don't have
-write permissions there either, so I'll try and see what happens.
-
-given all the funky security stuff recently, I really need to call luseradd
-to get the user added. Wish there was a C programming interface. My gosh,
-python has one, and you can't if setuid root python programs.
+++ /dev/null
-
-Real uid is a poorly named term for the uid of the user who launched the
-process. The uid that the process has been set to is the effective uid. There
-is a third stored uid in a process's record. Hence the uid being used by the
-OS will be set to one of these.
-
-Our subu-mk-0 program wants to create a subservient user to a master user. The
-master user is known via the real uid. The effective user will be that of root,
-as the script needs root privilege to run adduser.
-
-sudo resets the real uid, and there is no reliable approch then to create a subu-mk-0
-program run by sudo. A setuid root program is needed. Only compiled executables can
-be setuid root on linux.
-
-There is an environment variable given to programs run by sudo, $SUDO_USER. Sudo sets
-it, so if called from sudo then that works. It could be set by another user, even
-if that user is root or not.
-
-I will make a setuid C program. Too bad, had written this in Python.
+++ /dev/null
-
- src-da a simple doubling size expanding array in C
- src-tranche splits source code into multiple files. A poor man's 'makeheaders'.
-src-dispatch runs a function or shell command as a separate process
- src-db sqlite schema and interface for subu
- src-0 The layer 0 commands for subu. Some are setuid root programs.
- src-py The application layer
-
-
+++ /dev/null
-I. If we allowed the subu_home directory to be put anywhere, this script could
- be used by masteru gain access to any directory on the system. Hence, we have
- to add some constraints:
-
- constraint 1) the subuhome directory must not already exist, not as a
- directory or as any other type of object.
-
- constraint 2) masteru must already have privledges to reach access $(masteru_home)/subuland
-
- constraint 3) subuhome may only be placed under the directory $(masteru_home)/subuland.
-
- convention 4) only subuhome directories may be placed in $(masteru_home)/subuland.
-
- -> without constraint 1), exploit 1
-
- Suppose that a wily masteru was able to move an inaccessible directory that
- he or she wanted access to and place it under $(masteru_home)/subuland.
- Typically such directories are not moveable by wiley users in the first
- place, but suppose the wily masteru found such a directory.
-
- Alternatively suppose the wily masteru made a directory under
- $(masteru_home)/subuland of his or her own, and placed an inaccessible file
- or subdirectory inside of it.
-
- Alternatively suppose that the wily masteru made $(masteru_home)/subuland a
- hard link or a symlink to a directory that contained a subdirectory that
- masteru did not have access to.
-
- The the wiley masteru could then create a subu by the same name as the
- directory he desired access to, and trick the foolish subu-mk-0 into giving
- him or her access.
-
- -> without constraint 2) exploit 2
-
- Then the masteru could place subu directories in places he can not access.
- The foolish subu-mk-0 program would then add 'x' acls to as to reach this
- place. The masteru could then change identity to the subu, (i.e. enter the
- container), and then reach that place he or she could not reach before.
-
- -> without constraint 3) exploit 3
-
- If masteru looses x privlege to a place, subu might keep it, and then
- exploit 2 would work despite the existence of constraint 2. It would be
- unusual that masteru not have x privledges to masteru_home. Furthmore, we
- decree that masteru has x privige to subuland. Hence, exploit 3 can be
- prevented by following this convention.
-
- -> without convention 4) exploit 4
-
-
-II. the ownership flaw
-
-subu will own the files and directories that it makes. The default acls are
-such that masteru will also have access to subu's file. This defines the master
-user / subservient user convention on the filesystem.
-
-However, because subu owns the files and directories, it can modify the
-acls. Thus a wily subu can lock the masteru out.
-
-Perhaps the master has a 'fix perms' script. However, there is no enshrined
-relationship in the system between the masteru and the subu, so the system won't
-know for sure the subu belongs to the masteru, and thus can not allow masteru to
-change the supposed subu's permissions to give back access to masteru.
-
-Perhaps we propose that instead masteru owns the files and directories of
-subuhome, and subu is given access privilege through acls and default acls.
-Indeed, then subu can't change the acls on these existing files. However, if
-subu is allowed to own processes, then those processes might create files owned
-by the subu, and the subu can lock the master out from access to these new
-files.
-
-How about a variation. Perhaps the subu shares the uid of the masteru, but has
-a different gid. The subuhome then has the sticky bit set on the group access,
-so all files created remain the same gid. subu process are masteru processes,
-however the gid of the process is that of the subu's. Masteru can then control
-both the files and the processes, but in absence of this control, the subu has
-control.
-
-Then we don't make a new user when we make a subu, we make a new group. We then
-have to add utilities for 'logging into the subu' which goes to a different home
-directory based on the group being logged into.
-
-III. other approaches
-
-Groups don't seem to offer much help, the owner is still the owner.
-
-A volume can be mounted without the subu being able to modify the facls. I
-don't know if the default facls still apply, but if so, then this would be a
-solution.
-
-bindfs can translate uids and gids. The same directory can appear in two
-places, in one place owned by the subu and in another owned by the masteru.
-This looks to be potentially a clean solution. It would also be recursive,
-i.e. a subu could have subus. I'll try this one.
-
-One possibility is for the subusers to appear in /home/ as normal users. Then
-masteru bindfs with translation into subuland. Everything in subuland appears
-to be owned by masteru. This is a transparent way to give masteru control over
-all the files.
-
-Then is the question of being able to control the processes being run by a subu.
-We will need an /etc/ file that pairs masters and subus.
-
-
+++ /dev/null
-
-subu is short for subservient user.
-
-A subu is much like any other user. It has an entry in /etc/passwd, and a home
-directory. As for other users this home directory is most likely under /home.
-Direct login to the subu might be barred, though that is not necessarly the case.
-
-Each subu has two names. One is its 'subu_username'. The other is its
-'subuname'. The subu_username is autogenerated. When using our tools, one
-never needs to know the subu_username. However, the entry in /etc/passwd will be
-the generated name, and the home directory will have the generated name. The
-command 'subu-username subuname' will print the subu_username.
-
-Each subu belongs to a master user, known as masteru. A given masteru may have many
-subus. The masteru is a different user than any of the subu's that are
-subservient to it.
-
-Each masteru has a top level subdirectory called 'subuland'. In this sub
-directory the masteru will find all of its subu home directories. The masteru
-will then see all subu owned files in the subuland through the illusion that the
-masteru owns them rather than the corresponding subu. Thus the master may move
-files around using a regular file navigator.
-
-Actually the subus will not appear in subuland until masteru runs the command
-'subu-mount'. This is normally done when masteru logs in.
-
-The masteru may create and delete subus at will. The masteru may set default
-nice values, renice, or kill subu processes. The masteru may set limits for a
-subu. In fact, the masteru is a bit like root relative to its subus.
-
-There is a control panel that masteru may use. It has a matrix of rectangles,
-where in each rectangle, there is information about each subu's processes and
-disk usage.
-
-The masteru may set the subu for each launched process.
-
----
-subu-username <subuname>
-
-prints the username
-returns an error code
-
----
-subu-number
-
-prints a new maximums subu number.
-returns an error code
-
-These numbers are used in synthesizing usernames. Used for testing, should not
-appear in any scripts.
-
----
-subu-mount
-
-mounts all of the subus for the given masteru
-returns an error code
-
----
-subu-mk-0 <subuname>
-
-primitve makes a new subu
-returns an error code
-
----
-subu-rm-0 <subuname>
-
-primitive removes a subu
-returns an error code
+++ /dev/null
-
-note the 'ownerhips flaw' in subu-mk-0.txt. Could groups help with this?
-
-Suppose that instead of creating the subu as a separate user, it is created as a group. Masteru then has a
-number of separate groups. To run a process as the subu, the uid is set to the masteru, and the gid is set
-to the subu. .. but then the process would be able to modify anything owned by masteru
-
-suppose subu belongs to masteru's group .. then all subus are the same and can write each other's data.
-
-suppose masteru belongs to subu's group .. subu is still its own unique user, so it can change group permissions
-on files it makes and lock masteru out.
-
-suppose there is a unique third party, the mediator. Both masteru and subu belong to its group. A
-processes running as subu can only create files in directories that have mediator group permissions. subu still
-owns the files and directories it creates, so ..
-
-suppose the group sticky bit is set. The subu must belong to the group to write anything in the directories.
-Anything it writes are owned by the group. Suppose masteru is also in the this group. Though a mean subu
-could not take away the group ownership, it could
-
-
-
+++ /dev/null
-
-sudo_leak_script - demonstrates script injection through the pompt environement variable
-SUDO_USER - shows that userland scripts can trick other scripts into believing they are running under sudo.
-print_env.py - prints getuid, geteuid, some other info, and the value of each environment variable
-libuser - try out libuser
--- /dev/null
+
+~ is the project directory
+
+--------------------------------------------------------------------------------
+most subdirectories are source modules
+
+
+--------------------------------------------------------------------------------
+~/tools
+
+Some tools are normally installed on the system. Others are local. Local tools
+are typically standard tools that have been customized for the project or are
+unusual to the project.
+
+ ~/tools/bin is for the executables of locally used tools.
+ ~/tools/lib is locally used libraries.
+ ~/tools/doc is for collected docs on tools
+
+typically a developer will want ~/tools/bin in his search path
+
+--------------------------------------------------------------------------------
+~/staged
+
+These are make file build targets. They represent either intermediate or
+finished executables and libraries. When a project has multiple src
+directories and they use each other's work product for the builds, the
+items in the staged area are those that are used by each src directory.
+
+Typically the install target copies material in the staging area to
+system locations.
+
+--------------------------------------------------------------------------------
+~/<module>
+
+
+
+
+
--- /dev/null
+
+
+filename.tag.extension
+
+extension:
+ .c for C source
+ .cc for C++ source
+ .h for C header file
+ .hh for C++ header file
+ .o an object file
+
+tag:
+ .lib. The resulting .o file to be placed in release library and is part of the
+ programming interface.
+ .aux. The resulting.o file not directly part of the programming interface, but
+ it might be called by functions that are.
+ .cli. The source file has a main call and is to be relased as part of the command line interface
+ .loc. file has a main call to be made into a local uitlity function
+
+We carry the source file tag and extension to the .o file. We do not put tags
+nor extensions on command line executables.
+
+local_common.h should be included in all source files
--- /dev/null
+1.
+
+For the following makefile, the .PHONY tag is ignored unless there
+is an explicit target with that name. The %:: target is not enough.
+So for expample, if there is an exec directory, the exec target
+caught through the %:: will never fire. The commented lines must
+be added that give an explicit exec target.
+
+
+.PHONY: all version deps lib exec
+all: version deps lib exec
+
+lib:
+ $(MAKE) $@
+ cp src/tranche.lib.h include/tranche.h
+
+#exec:
+# $(MAKE) $@
+
+%::
+ $(MAKE) $@
--- /dev/null
+
+subu-mk-0
+
+ 1. We have to make the subu for step 2 so that we will have subu_uid and subu_gid
+ to work with, but we delay this for as long as possible, as the program might
+ first bail due to other errors.
+
+ 2. Then we add user access via setfacl to masteru's home directory and to
+ subu_land, so that we have permissions to make the home directory.
+
+ 3. Then as subu we create the home directory. .. I wonder where the system
+ gets the umask for this? Perhaps we should create the dir, and then change
+ the ownership instead?
+
+ 4. Still as subu, we add facls to our directory to give masteru access.
+
+finished, good part is that we never need to move back to root.
+
+setfacl -m u:subu:x masteru
+setfacl -m u:subu:x masteru/subu_land
+setfacl -m d:u:masteru:rwX,u:masteru:rwX subu
+
+
+using luseradd to make the subu is a circular problem because we need to setfacls
+to allow the creating of the home directory inside the masteru/subu_land, but
+to set facls we need the uid from luseradd. So..
+ 1. luseradd without creation of a home directory. We can provide the path,
+ but can't create it.
+ 2. get the uid, and set the facls
+ 3. create the home directory
+
+Step 3 is a bit of a problem, because subu's don't have write permission for
+subu_land/
+
+.. or maybe not, luseradd puts users in /home, but those users don't have
+write permissions there either, so I'll try and see what happens.
+
+given all the funky security stuff recently, I really need to call luseradd
+to get the user added. Wish there was a C programming interface. My gosh,
+python has one, and you can't if setuid root python programs.
--- /dev/null
+
+Real uid is a poorly named term for the uid of the user who launched the
+process. The uid that the process has been set to is the effective uid. There
+is a third stored uid in a process's record. Hence the uid being used by the
+OS will be set to one of these.
+
+Our subu-mk-0 program wants to create a subservient user to a master user. The
+master user is known via the real uid. The effective user will be that of root,
+as the script needs root privilege to run adduser.
+
+sudo resets the real uid, and there is no reliable approch then to create a subu-mk-0
+program run by sudo. A setuid root program is needed. Only compiled executables can
+be setuid root on linux.
+
+There is an environment variable given to programs run by sudo, $SUDO_USER. Sudo sets
+it, so if called from sudo then that works. It could be set by another user, even
+if that user is root or not.
+
+I will make a setuid C program. Too bad, had written this in Python.
--- /dev/null
+
+ src-da a simple doubling size expanding array in C
+ src-tranche splits source code into multiple files. A poor man's 'makeheaders'.
+src-dispatch runs a function or shell command as a separate process
+ src-db sqlite schema and interface for subu
+ src-0 The layer 0 commands for subu. Some are setuid root programs.
+ src-py The application layer
+
+
--- /dev/null
+I. If we allowed the subu_home directory to be put anywhere, this script could
+ be used by masteru gain access to any directory on the system. Hence, we have
+ to add some constraints:
+
+ constraint 1) the subuhome directory must not already exist, not as a
+ directory or as any other type of object.
+
+ constraint 2) masteru must already have privledges to reach access $(masteru_home)/subuland
+
+ constraint 3) subuhome may only be placed under the directory $(masteru_home)/subuland.
+
+ convention 4) only subuhome directories may be placed in $(masteru_home)/subuland.
+
+ -> without constraint 1), exploit 1
+
+ Suppose that a wily masteru was able to move an inaccessible directory that
+ he or she wanted access to and place it under $(masteru_home)/subuland.
+ Typically such directories are not moveable by wiley users in the first
+ place, but suppose the wily masteru found such a directory.
+
+ Alternatively suppose the wily masteru made a directory under
+ $(masteru_home)/subuland of his or her own, and placed an inaccessible file
+ or subdirectory inside of it.
+
+ Alternatively suppose that the wily masteru made $(masteru_home)/subuland a
+ hard link or a symlink to a directory that contained a subdirectory that
+ masteru did not have access to.
+
+ The the wiley masteru could then create a subu by the same name as the
+ directory he desired access to, and trick the foolish subu-mk-0 into giving
+ him or her access.
+
+ -> without constraint 2) exploit 2
+
+ Then the masteru could place subu directories in places he can not access.
+ The foolish subu-mk-0 program would then add 'x' acls to as to reach this
+ place. The masteru could then change identity to the subu, (i.e. enter the
+ container), and then reach that place he or she could not reach before.
+
+ -> without constraint 3) exploit 3
+
+ If masteru looses x privlege to a place, subu might keep it, and then
+ exploit 2 would work despite the existence of constraint 2. It would be
+ unusual that masteru not have x privledges to masteru_home. Furthmore, we
+ decree that masteru has x privige to subuland. Hence, exploit 3 can be
+ prevented by following this convention.
+
+ -> without convention 4) exploit 4
+
+
+II. the ownership flaw
+
+subu will own the files and directories that it makes. The default acls are
+such that masteru will also have access to subu's file. This defines the master
+user / subservient user convention on the filesystem.
+
+However, because subu owns the files and directories, it can modify the
+acls. Thus a wily subu can lock the masteru out.
+
+Perhaps the master has a 'fix perms' script. However, there is no enshrined
+relationship in the system between the masteru and the subu, so the system won't
+know for sure the subu belongs to the masteru, and thus can not allow masteru to
+change the supposed subu's permissions to give back access to masteru.
+
+Perhaps we propose that instead masteru owns the files and directories of
+subuhome, and subu is given access privilege through acls and default acls.
+Indeed, then subu can't change the acls on these existing files. However, if
+subu is allowed to own processes, then those processes might create files owned
+by the subu, and the subu can lock the master out from access to these new
+files.
+
+How about a variation. Perhaps the subu shares the uid of the masteru, but has
+a different gid. The subuhome then has the sticky bit set on the group access,
+so all files created remain the same gid. subu process are masteru processes,
+however the gid of the process is that of the subu's. Masteru can then control
+both the files and the processes, but in absence of this control, the subu has
+control.
+
+Then we don't make a new user when we make a subu, we make a new group. We then
+have to add utilities for 'logging into the subu' which goes to a different home
+directory based on the group being logged into.
+
+III. other approaches
+
+Groups don't seem to offer much help, the owner is still the owner.
+
+A volume can be mounted without the subu being able to modify the facls. I
+don't know if the default facls still apply, but if so, then this would be a
+solution.
+
+bindfs can translate uids and gids. The same directory can appear in two
+places, in one place owned by the subu and in another owned by the masteru.
+This looks to be potentially a clean solution. It would also be recursive,
+i.e. a subu could have subus. I'll try this one.
+
+One possibility is for the subusers to appear in /home/ as normal users. Then
+masteru bindfs with translation into subuland. Everything in subuland appears
+to be owned by masteru. This is a transparent way to give masteru control over
+all the files.
+
+Then is the question of being able to control the processes being run by a subu.
+We will need an /etc/ file that pairs masters and subus.
+
+
--- /dev/null
+
+subu is short for subservient user.
+
+A subu is much like any other user. It has an entry in /etc/passwd, and a home
+directory. As for other users this home directory is most likely under /home.
+Direct login to the subu might be barred, though that is not necessarly the case.
+
+Each subu has two names. One is its 'subu_username'. The other is its
+'subuname'. The subu_username is autogenerated. When using our tools, one
+never needs to know the subu_username. However, the entry in /etc/passwd will be
+the generated name, and the home directory will have the generated name. The
+command 'subu-username subuname' will print the subu_username.
+
+Each subu belongs to a master user, known as masteru. A given masteru may have many
+subus. The masteru is a different user than any of the subu's that are
+subservient to it.
+
+Each masteru has a top level subdirectory called 'subuland'. In this sub
+directory the masteru will find all of its subu home directories. The masteru
+will then see all subu owned files in the subuland through the illusion that the
+masteru owns them rather than the corresponding subu. Thus the master may move
+files around using a regular file navigator.
+
+Actually the subus will not appear in subuland until masteru runs the command
+'subu-mount'. This is normally done when masteru logs in.
+
+The masteru may create and delete subus at will. The masteru may set default
+nice values, renice, or kill subu processes. The masteru may set limits for a
+subu. In fact, the masteru is a bit like root relative to its subus.
+
+There is a control panel that masteru may use. It has a matrix of rectangles,
+where in each rectangle, there is information about each subu's processes and
+disk usage.
+
+The masteru may set the subu for each launched process.
+
+---
+subu-username <subuname>
+
+prints the username
+returns an error code
+
+---
+subu-number
+
+prints a new maximums subu number.
+returns an error code
+
+These numbers are used in synthesizing usernames. Used for testing, should not
+appear in any scripts.
+
+---
+subu-mount
+
+mounts all of the subus for the given masteru
+returns an error code
+
+---
+subu-mk-0 <subuname>
+
+primitve makes a new subu
+returns an error code
+
+---
+subu-rm-0 <subuname>
+
+primitive removes a subu
+returns an error code
--- /dev/null
+
+note the 'ownerhips flaw' in subu-mk-0.txt. Could groups help with this?
+
+Suppose that instead of creating the subu as a separate user, it is created as a group. Masteru then has a
+number of separate groups. To run a process as the subu, the uid is set to the masteru, and the gid is set
+to the subu. .. but then the process would be able to modify anything owned by masteru
+
+suppose subu belongs to masteru's group .. then all subus are the same and can write each other's data.
+
+suppose masteru belongs to subu's group .. subu is still its own unique user, so it can change group permissions
+on files it makes and lock masteru out.
+
+suppose there is a unique third party, the mediator. Both masteru and subu belong to its group. A
+processes running as subu can only create files in directories that have mediator group permissions. subu still
+owns the files and directories it creates, so ..
+
+suppose the group sticky bit is set. The subu must belong to the group to write anything in the directories.
+Anything it writes are owned by the group. Suppose masteru is also in the this group. Though a mean subu
+could not take away the group ownership, it could
+
+
+
--- /dev/null
+
+sudo_leak_script - demonstrates script injection through the pompt environement variable
+SUDO_USER - shows that userland scripts can trick other scripts into believing they are running under sudo.
+print_env.py - prints getuid, geteuid, some other info, and the value of each environment variable
+libuser - try out libuser
+++ /dev/null
-#!/bin/bash
-# must have commands rsync and user-stem
-# user-stem is in the system repo
-#
-# wish we could set the uids and gids so that backups would restore properly on other systems but it is too much trouble
-# to do in a shell script. Perhaps in the python code for the actual release.
-
-subu=$1
-
-
-if [ ! -x "/usr/local/bin/user-stem" ]; then
- echo "no /usr/local/bin/user-stem program found (it is in the system repo)"
- exit 1
-fi
-
-if [ -z "$subu" ]; then
- echo "no subuser name supplied"
- exit 1
-fi
-
-# stem includes all characters up to the first '-'
-stem=$(/usr/local/bin/user-stem)
-
-user_subu="$stem-$subu"
-user_admin="$stem-admin"
-
-home_subu="/home/$stem/$subu"
-home_admin="/home/$stem/admin"
-
-sudo useradd --home-dir "$home_subu" "$user_subu"
-sudo usermod -aG "$user_subu" "$user_admin"
-sudo find "$home_admin/subu_default" -mindepth 1 -execdir cp -p {} "$home_subu" \;
-sudo find "$home_subu" -execdir chown "$user_subu":"$user_subu" {} \;
-
-
+++ /dev/null
-#!/bin/bash
-# must have command user-stem
-# user-stem is in the system repo
-#
-# currently this is setup to be run by any user who has sudo - it doesn't have to be run by the user-admin account; though chances are it will be.
-#
-# userdel -r deletes both the /var/spool/mail/user and the user's home directory. We don't want to delete the old data just in case there
-# is something important there. However we can not leve the old /var/spool/mail/user file under /var/spool/mail in case another subu is
-# created later with the same name. Hence we will move the /var/spool/mail/user file into the users home directory. We will give ownership
-# of the old home directory to the admin.
-#
-# I have run into a problem that subu users do not inherit the MAIL variable, I wouldn't trust it anyway. I do not know if userdel -r
-# references the MAIL variable. I will hard code a local variable to /var/sppol/mail. This must be changed for systems that put the mail spool
-# file eleswhere.
-#
-#set -x
-
-subu=$1
-
-if [ ! -x "/usr/local/bin/user-stem" ]; then
- echo "no /usr/local/bin/user-stem program found (it is in the system repo)"
- exit 1
-fi
-
-if [ -z "$subu" ]; then
- echo "no subuser name supplied"
- exit 1
-fi
-
-# stem includes all characters up to the first '-'
-stem=$(/usr/local/bin/user-stem)
-user_subu="$stem-$subu"
-user_admin="$stem-admin"
-home_subu="/home/$stem/$subu"
-archive_suffix=_former_subu
-archive_subu="$home_subu$archive_suffix"
-mail_source_dir="/var/spool/mail"
-mail_source_file="$mail_source_dir/$user_subu"
-mail_target_file="$home_subu/mail_spool"
-
-if [ -e "$archive_subu" ]; then
- echo "there is already a saved directory for a deleted subu with this name, move this out of the way first: $archive_subu"
- exit 1
-fi
-if [ ! -d "$mail_source_dir" ]; then
- echo "could not find mail spooler directory: $mail_source_dir"
- exit 1
-fi
-
-if [ -e "$mail_target_file" ]; then
- echo "there is already file system object where we planned to move the deleted user's mail spool, which is here: $home_subu/mail_spool"
- exit 1
-fi
-
-sudo killall --signal 5 --user "$user_subu"
-sudo mv "$mail_source_file" "$mail_target_file"
-sudo chmod -R go-rwx "$home_subu"
-sudo chown -R "$user_admin":"$user_admin" "$home_subu"
-mv "$home_subu" "$archive_subu"
-sudo groupdel -f "$user_subu"
-sudo userdel "$user_subu"
-
-#set +x
--- /dev/null
+#!/bin/bash
+#
+# This must be sourced
+
+subu=$1
+if [ -z "$subu" ]; then
+ echo "no subuser name supplied"
+ exit 1
+fi
+
+machine="$(hostname)"
+xkey=$(xauth list | grep Turbine | awk '{print $3}')
+
+if [ -z "$key" ]; then
+ echo "xauth key not found"
+ exit 1
+fi
+
+sudo su "$subu"
+
+xauth
\ No newline at end of file
--- /dev/null
+#!/bin/bash
+# must have commands rsync and user-stem
+# user-stem is in the system repo
+#
+# wish we could set the uids and gids so that backups would restore properly on other systems but it is too much trouble
+# to do in a shell script. Perhaps in the python code for the actual release.
+
+subu=$1
+
+
+if [ ! -x "/usr/local/bin/user-stem" ]; then
+ echo "no /usr/local/bin/user-stem program found (it is in the system repo)"
+ exit 1
+fi
+
+if [ -z "$subu" ]; then
+ echo "no subuser name supplied"
+ exit 1
+fi
+
+# stem includes all characters up to the first '-'
+stem=$(/usr/local/bin/user-stem)
+
+user_subu="$stem-$subu"
+user_admin="$stem-admin"
+
+home_subu="/home/$stem/$subu"
+home_admin="/home/$stem/admin"
+
+sudo useradd --home-dir "$home_subu" "$user_subu"
+sudo usermod -aG "$user_subu" "$user_admin"
+sudo find "$home_admin/subu_default" -mindepth 1 -execdir cp -p {} "$home_subu" \;
+sudo find "$home_subu" -execdir chown "$user_subu":"$user_subu" {} \;
+
+
--- /dev/null
+#!/bin/bash
+# must have command user-stem
+# user-stem is in the system repo
+#
+# currently this is setup to be run by any user who has sudo - it doesn't have to be run by the user-admin account; though chances are it will be.
+#
+# userdel -r deletes both the /var/spool/mail/user and the user's home directory. We don't want to delete the old data just in case there
+# is something important there. However we can not leve the old /var/spool/mail/user file under /var/spool/mail in case another subu is
+# created later with the same name. Hence we will move the /var/spool/mail/user file into the users home directory. We will give ownership
+# of the old home directory to the admin.
+#
+# I have run into a problem that subu users do not inherit the MAIL variable, I wouldn't trust it anyway. I do not know if userdel -r
+# references the MAIL variable. I will hard code a local variable to /var/sppol/mail. This must be changed for systems that put the mail spool
+# file eleswhere.
+#
+#set -x
+
+subu=$1
+
+if [ ! -x "/usr/local/bin/user-stem" ]; then
+ echo "no /usr/local/bin/user-stem program found (it is in the system repo)"
+ exit 1
+fi
+
+if [ -z "$subu" ]; then
+ echo "no subuser name supplied"
+ exit 1
+fi
+
+# stem includes all characters up to the first '-'
+stem=$(/usr/local/bin/user-stem)
+user_subu="$stem-$subu"
+user_admin="$stem-admin"
+home_subu="/home/$stem/$subu"
+archive_suffix=_former_subu
+archive_subu="$home_subu$archive_suffix"
+mail_source_dir="/var/spool/mail"
+mail_source_file="$mail_source_dir/$user_subu"
+mail_target_file="$home_subu/mail_spool"
+
+if [ -e "$archive_subu" ]; then
+ echo "there is already a saved directory for a deleted subu with this name, move this out of the way first: $archive_subu"
+ exit 1
+fi
+if [ ! -d "$mail_source_dir" ]; then
+ echo "could not find mail spooler directory: $mail_source_dir"
+ exit 1
+fi
+
+if [ -e "$mail_target_file" ]; then
+ echo "there is already file system object where we planned to move the deleted user's mail spool, which is here: $home_subu/mail_spool"
+ exit 1
+fi
+
+sudo killall --signal 5 --wait --user "$user_subu"
+sudo mv "$mail_source_file" "$mail_target_file"
+sudo chmod -R go-rwx "$home_subu"
+sudo chown -R "$user_admin":"$user_admin" "$home_subu"
+mv "$home_subu" "$archive_subu"
+sudo groupdel -f "$user_subu"
+sudo userdel "$user_subu"
+
+#set +x
--- /dev/null
+
+subu=$1
+
+whoami
+sudo su $subu
+whoami
\ No newline at end of file
projects / subu / commitdiff