How to disallow logout
I have a directory that must not exist on logout and rm -rf is not sufficent to do it because the contents need to be processed by our version control system. The real life scenario is our version control system stores the repo for a given project encrypted but for techinical reasons it needs to keep the checkouted files in plain text (they are all in the same dir) and I want to *NEVER* have the plain text checkouted files in my dir when I logout, *BUT* instead of just deleting it I need to check them in... so how do I make my .logout so if the file exists it will not exit and give a error saying that dir is still there? (minor but unimportant side effect of the version control system is the dir will have a different name everytime it is made but always the same prefix) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On Thu, 9 Sep 2010, Aryeh Friedman wrote: I have a directory that must not exist on logout and rm -rf is not sufficent to do it because the contents need to be processed by our version control system. = what i would do... make an alias or function of "logout" and/or "exit" in the init file that's parsed when the shell starts. alias it to a script or assign it to a function that does what you need. if your shell supports logging out with ^D (or any other keybinding) then the details may be shell-specific, but the idea would be to either disable it, or bind it to the script. -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
Perhaps you could write something to wrap your shell... basically you could set your login shell to this wrapper. First thing the wrapper would do is exec and wait on the shell, and when the shell exits, check what needs to be checked, and should any of these checks fail, respawn the shell and dump the user back into their login shell. That way you can't neglect any funky corner cases of the shell exiting... the shell exits, the checks happen. In this example, the user is forced to exit 3 times. The experience is pretty seemless, the only issue is that the user will lose their environment after failing and ending up back in the new respawned shell, but I don't see how this would be an issue if the user is hastefully logging out. shell-A$ for i in 1 2 3; do bash; echo poop; done child-1-of-A$ exit exit poop child-2-of-A$ exit exit poop child-3-of-A$ exit exit poop shell-A$ exit exit parent-of-A% exit E On Thu, Sep 9, 2010 at 8:34 PM, Atom Smasher wrote: > On Thu, 9 Sep 2010, Aryeh Friedman wrote: > >> I have a directory that must not exist on logout and rm -rf is not >> sufficent to do it because the contents need to be processed by our version >> control system. > > = > > what i would do... make an alias or function of "logout" and/or "exit" in > the init file that's parsed when the shell starts. alias it to a script or > assign it to a function that does what you need. > > if your shell supports logging out with ^D (or any other keybinding) then > the details may be shell-specific, but the idea would be to either disable > it, or bind it to the script. > > > -- > ...atom > > > http://atom.smasher.org/ > 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 > - > > "The reasonable man adapts himself to the world; the > unreasonable one persists in trying to adapt the world to > himself. Therefore all progress depends on the > unreasonable man." > -- George Bernard Shaw > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > -- --- Evan Geller thes...@gmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On 09/10/10 05:27, Aryeh Friedman wrote: I have a directory that must not exist on logout and rm -rf is not sufficent to do it because the contents need to be processed by our version control system. The real life scenario is our version control system stores the repo for a given project encrypted but for techinical reasons it needs to keep the checkouted files in plain text (they are all in the same dir) and I want to *NEVER* have the plain text checkouted files in my dir when I logout, *BUT* instead of just deleting it I need to check them in... so how do I make my .logout so if the file exists it will not exit and give a error saying that dir is still there? (minor but unimportant side effect of the version control system is the dir will have a different name everytime it is made but always the same prefix) Have you thought about what should happen if for example, the login session is forcefully terminated by either of: 1) power outage of the server 2) power outage on the client 3) network problems (ssh or TCP connection drop) 4) administrative command (e.g. root executes "killall $shell") ? I don't think there is a way to protect from all of those, so any effort in protecting from only part of the problem looks useless. On the other hand, if partial solutions satisfy your requirements, maybe you can do something with http://glebkurtsou.blogspot.com/search/label/pefs . ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On Fri, 10 Sep 2010, Ivan Voras wrote: 1) power outage of the server 2) power outage on the client 3) network problems (ssh or TCP connection drop) 4) administrative command (e.g. root executes "killall $shell") ? I don't think there is a way to protect from all of those, so any effort in protecting from only part of the problem looks useless. you forgot cosmic rays, nuclear war and zombie apocalypse, among other failure modes. *NOTHING* is capable of protecting against everything; a good solution will most always have pitfalls; as a sysadmin/engineer/manager one has to either accept the pitfalls or find a more acceptable solution, which usually means different pitfalls. that doesn't mean a given solution is useless. -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - "I am committed to helping Ohio deliver its electoral votes to the president [Bush] next year" -- Walden O'Dell, CEO of Diebold August 2003 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On 10 September 2010 14:11, Atom Smasher wrote: > On Fri, 10 Sep 2010, Ivan Voras wrote: > >> 1) power outage of the server >> 2) power outage on the client >> 3) network problems (ssh or TCP connection drop) >> 4) administrative command (e.g. root executes "killall $shell") >> >> ? >> >> I don't think there is a way to protect from all of those, so any effort >> in protecting from only part of the problem looks useless. > > > > you forgot cosmic rays, nuclear war and zombie apocalypse, among other > failure modes. *NOTHING* is capable of protecting against everything; a good > solution will most always have pitfalls; as a sysadmin/engineer/manager one > has to either accept the pitfalls or find a more acceptable solution, which > usually means different pitfalls. that doesn't mean a given solution is > useless. On the other hand, things such as power outages, network blackouts and and root security compromises have been statistically shown to appear more often than zombie apocalypses, so I'd guess, though of course without absolute certainty, that those problem should be solved first :) Otherwise, it's just as effective as putting a README file in the home directory saying "please go away" :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On Thu, Sep 9, 2010 at 8:27 PM, Aryeh Friedman wrote: > I have a directory that must not exist on logout and rm -rf is not > sufficent to do it because the contents need to be processed by our > version control system. The real life scenario is our version > control system stores the repo for a given project encrypted but for > techinical reasons it needs to keep the checkouted files in plain text > (they are all in the same dir) and I want to *NEVER* have the plain > text checkouted files in my dir when I logout, *BUT* instead of just > deleting it I need to check them in... so how do I make my .logout so > if the file exists it will not exit and give a error saying that dir > is still there? (minor but unimportant side effect of the version > control system is the dir will have a different name everytime it is > made but always the same prefix) This is probably a silly suggestion, but as I see it there is another option: a periodic script which goes and commits the files if the sessions go away (via crontab, or whatever). In particular, this would solve the problem if one of the sessions you had quit, but you had more than one session open to the machine. Of course if you didn't care about the contents of the files you could take a different approach and employ something similar in .login, but it doesn't sound like that's what you want to do either, and that wouldn't solve the multi-session problem... Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
The problem with that is our version control system (devel/aegis) purposely does not allow arbitary checkins... there is a whole procedure of you have to prove it compiles and passes at least one new test and then an other person needs to review the change and then and only then can it be checked in (and even here you need to repeat the proof of build and one new test [same as the ones above] to ensure that passing the test was not a fluke of your local environment)... this project is setup so I play all 3 roles on it but all three phases have to be formally done to check it in... btw the whole goal here (unlike non-atomic VCS's like SVN [git does it to some extent] the goal here is to make sure that nothing breaks the baseline [the fully tested and reviewed repo]). On Fri, Sep 10, 2010 at 1:03 PM, Garrett Cooper wrote: > On Thu, Sep 9, 2010 at 8:27 PM, Aryeh Friedman > wrote: >> I have a directory that must not exist on logout and rm -rf is not >> sufficent to do it because the contents need to be processed by our >> version control system. The real life scenario is our version >> control system stores the repo for a given project encrypted but for >> techinical reasons it needs to keep the checkouted files in plain text >> (they are all in the same dir) and I want to *NEVER* have the plain >> text checkouted files in my dir when I logout, *BUT* instead of just >> deleting it I need to check them in... so how do I make my .logout so >> if the file exists it will not exit and give a error saying that dir >> is still there? (minor but unimportant side effect of the version >> control system is the dir will have a different name everytime it is >> made but always the same prefix) > > This is probably a silly suggestion, but as I see it there is > another option: a periodic script which goes and commits the files if > the sessions go away (via crontab, or whatever). In particular, this > would solve the problem if one of the sessions you had quit, but you > had more than one session open to the machine. > Of course if you didn't care about the contents of the files you > could take a different approach and employ something similar in > .login, but it doesn't sound like that's what you want to do either, > and that wouldn't solve the multi-session problem... > Cheers, > -Garrett > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On Fri 10 Sep 2010 at 10:09:20 PDT Aryeh Friedman wrote: The problem with that is our version control system (devel/aegis) purposely does not allow arbitary checkins... there is a whole procedure of you have to prove it compiles and passes at least one new test and then an other person needs to review the change and then and only then can it be checked in (and even here you need to repeat the proof of build and one new test [same as the ones above] to ensure that passing the test was not a fluke of your local environment)... this project is setup so I play all 3 roles on it but all three phases have to be formally done to check it in... btw the whole goal here (unlike non-atomic VCS's like SVN [git does it to some extent] the goal here is to make sure that nothing breaks the baseline [the fully tested and reviewed repo]). Is this something for your personal use, or are you looking for a solution that can be deployed throughout your company? If the latter, it seems to me that by making it more onerous to logout, you're simply going to be encouraging more people to leave their desks without logging out. Do you have a plan for securing their unattended but still logged-in workstations? Even if you do secure the workstations, what have you actually achieved? Somebody could still check out some files, go home for the weekend, then call in sick on Monday and Tuesday. The files are checked out all this time, and as far as I can see, the situation is no better than if he'd logged out Friday afternoon without checking in the files. You should probably think about these scenarios even if you were intending to implement this for your personal use only. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On 09/09/2010 23:27, Aryeh Friedman wrote: > I have a directory that must not exist on logout and rm -rf is not > sufficent to do it because the contents need to be processed by our > version control system. The real life scenario is our version > control system stores the repo for a given project encrypted but for > techinical reasons it needs to keep the checkouted files in plain text > (they are all in the same dir) and I want to *NEVER* have the plain > text checkouted files in my dir when I logout, *BUT* instead of just > deleting it I need to check them in... so how do I make my .logout so > if the file exists it will not exit and give a error saying that dir > is still there? (minor but unimportant side effect of the version > control system is the dir will have a different name everytime it is > made but always the same prefix) > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" trap '/path/to/your_wrapper_script.HERE' 2 Should execute the contents of that script on every logout. Whether that script is a line by line action or a fully qualified script with functions to call different actions are up to you. Good luck, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On 09/10/2010 22:21, jhell wrote: > On 09/09/2010 23:27, Aryeh Friedman wrote: >> I have a directory that must not exist on logout and rm -rf is not >> sufficent to do it because the contents need to be processed by our >> version control system. The real life scenario is our version >> control system stores the repo for a given project encrypted but for >> techinical reasons it needs to keep the checkouted files in plain text >> (they are all in the same dir) and I want to *NEVER* have the plain >> text checkouted files in my dir when I logout, *BUT* instead of just >> deleting it I need to check them in... so how do I make my .logout so >> if the file exists it will not exit and give a error saying that dir >> is still there? (minor but unimportant side effect of the version >> control system is the dir will have a different name everytime it is >> made but always the same prefix) >> ___ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > > trap '/path/to/your_wrapper_script.HERE' 2 > This should be: trap '/path/to/script' EXIT > Should execute the contents of that script on every logout. Whether that > script is a line by line action or a fully qualified script with > functions to call different actions are up to you. > > Good luck, > -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On Fri, Sep 10, 2010 at 10:30:35PM -0400, jhell wrote: > On 09/10/2010 22:21, jhell wrote: > > On 09/09/2010 23:27, Aryeh Friedman wrote: > >> I have a directory that must not exist on logout and rm -rf is not > >> sufficent to do it because the contents need to be processed by our > >> version control system. The real life scenario is our version > >> control system stores the repo for a given project encrypted but for > >> techinical reasons it needs to keep the checkouted files in plain text > >> (they are all in the same dir) and I want to *NEVER* have the plain > >> text checkouted files in my dir when I logout, *BUT* instead of just > >> deleting it I need to check them in... so how do I make my .logout so > >> if the file exists it will not exit and give a error saying that dir > >> is still there? (minor but unimportant side effect of the version > >> control system is the dir will have a different name everytime it is > >> made but always the same prefix) > >> ___ > >> freebsd-hackers@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > > > > trap '/path/to/your_wrapper_script.HERE' 2 > > > > This should be: > > trap '/path/to/script' EXIT > > > Should execute the contents of that script on every logout. Whether that > > script is a line by line action or a fully qualified script with > > functions to call different actions are up to you. ...but, of course, that's only until people learn that they can bypass this by something like 'kill -FPE $$'. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. signature.asc Description: Digital signature
Re: How to disallow logout
On 09/11/2010 05:07, Peter Pentchev wrote:
>
> ...but, of course, that's only until people learn that they can
> bypass this by something like 'kill -FPE $$'.
>
Have you tried that ?
If the person/developer is looking into it that far where they need to
subvert the logout process then there is probably a pretty good reason
for doing so and would be expected that they bring it to the admins
attention or file a PR.
There is only just so much you can do before you start to modify the
code in the shell itself so the user cant execute another shell upon
login and kill their shell before other scripts run on logout.
Firstly this just sounds like a case where the admin needs to provide a
equally sound and safe way of making sure everything is cleaned up on
logout and is offering a global way of doing it so the developer will
not forget.
trap 'echo "Sorry FPE not allowed. ;)"' FPE
( kill -l ) will list the rest of the signals you can trap too.
And you can get pretty evil with this. But for the short term.
for sig in `jot 31 1`; do
trap 'echo "WARN:$$ Please use ^D or logout(1) instead."' ${sig}
done
Of course not all of those signals will cause a logout to happen but
have fun with it.
Regards,
--
jhell,v
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
> > Firstly this just sounds like a case where the admin needs to provide a > equally sound and safe way of making sure everything is cleaned up on > logout and is offering a global way of doing it so the developer will > not forget. In this case the admin and developer are the same person... namely at the clients request I am the only person allowed to work on the project and I just want to make it so I can't accidently do something like control-d or something like that and leave a plain text version of a project that has a very strict NDA laying around (liquidated damages of $250k)... the scenrio is we a are a team (each one of us is in diff city) of freelance CS people and all use the same server for all our development to make cooperation possible when needed (not in this case) have centralized backups, etc. and as mentioned on this one project the client has forced me to sign a NDA saying I can't even show the code to the other team members without the client's permission and thus am storing the repo using security/fuse-encfs, but since the version control system (devel/aegis) requires creating a development directory that is not encrypted I want to force/remind myself to checkin what ever I was working into the encrypted repo when I go "home" (it is a home office ;-)) at night or out to lunch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On Sat, Sep 11, 2010 at 7:07 AM, Aryeh Friedman wrote: >> >> Firstly this just sounds like a case where the admin needs to provide a >> equally sound and safe way of making sure everything is cleaned up on >> logout and is offering a global way of doing it so the developer will >> not forget. > > In this case the admin and developer are the same person... namely at > the clients request I am the only person allowed to work on the > project and I just want to make it so I can't accidently do something > like control-d or something like that and leave a plain text version > of a project that has a very strict NDA laying around (liquidated > damages of $250k)... the scenrio is we a are a team (each one of us is > in diff city) of freelance CS people and all use the same server for > all our development to make cooperation possible when needed (not in > this case) have centralized backups, etc. and as mentioned on this one > project the client has forced me to sign a NDA saying I can't even > show the code to the other team members without the client's > permission and thus am storing the repo using security/fuse-encfs, but > since the version control system (devel/aegis) requires creating a > development directory that is not encrypted I want to force/remind > myself to checkin what ever I was working into the encrypted repo when > I go "home" (it is a home office ;-)) at night or out to lunch > Forgot to mention all these percautions are to make the client comfortable with letting me take advanatage of the server's development enviroment instead of spending almost a week configuring the same env on my desktop machine... namely I trust the other team members to not look at the code even if it was not encrypted. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On 09/11/2010 07:13, Aryeh Friedman wrote: > On Sat, Sep 11, 2010 at 7:07 AM, Aryeh Friedman > wrote: >>> >>> Firstly this just sounds like a case where the admin needs to provide a >>> equally sound and safe way of making sure everything is cleaned up on >>> logout and is offering a global way of doing it so the developer will >>> not forget. >> >> In this case the admin and developer are the same person... namely at >> the clients request I am the only person allowed to work on the >> project and I just want to make it so I can't accidently do something >> like control-d or something like that and leave a plain text version >> of a project that has a very strict NDA laying around (liquidated >> damages of $250k)... the scenrio is we a are a team (each one of us is >> in diff city) of freelance CS people and all use the same server for >> all our development to make cooperation possible when needed (not in >> this case) have centralized backups, etc. and as mentioned on this one >> project the client has forced me to sign a NDA saying I can't even >> show the code to the other team members without the client's >> permission and thus am storing the repo using security/fuse-encfs, but >> since the version control system (devel/aegis) requires creating a >> development directory that is not encrypted I want to force/remind >> myself to checkin what ever I was working into the encrypted repo when >> I go "home" (it is a home office ;-)) at night or out to lunch >> > > Forgot to mention all these percautions are to make the client > comfortable with letting me take advanatage of the server's > development enviroment instead of spending almost a week configuring > the same env on my desktop machine... namely I trust the other team > members to not look at the code even if it was not encrypted. In that case would it make sense to just use tmpfs or some other destructive file-system when it gets unmounted. Maybe one-time encryption offered by geli(8) on a mdconfig(8) swap-file for just the source that you checkout. Implement it using amd(8). Don't know if this is a possible scenario but gives you a little more to consider. Regards & good luck, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
Aryeh Friedman wrote: > In this case the admin and developer are the same person... namely at > the clients request I am the only person allowed to work on the > project and I just want to make it so I can't accidently do something > like control-d or something like that and leave a plain text version > of a project that has a very strict NDA laying around (liquidated > damages of $250k)... the scenrio is we a are a team (each one of us is > in diff city) of freelance CS people and all use the same server for > all our development to make cooperation possible when needed (not in > this case) have centralized backups, etc. and as mentioned on this one > project the client has forced me to sign a NDA saying I can't even > show the code to the other team members without the client's > permission and thus am storing the repo using security/fuse-encfs, but > since the version control system (devel/aegis) requires creating a > development directory that is not encrypted I want to force/remind > myself to checkin what ever I was working into the encrypted repo when > I go "home" (it is a home office ;-)) at night or out to lunch If it's just a reminder to yourself, then I would simply remove the keybinding for ^D (or bind it to something else; the details depend on your login shell) and alias "exit" and "logout" to a script that checks the working directory of your version control system. If things have been checked in correctly, it logs you out, otherwise it prints a message and terminates, throwing you back to the shell prompt. Additionally, you could put the checked-out files on a geli-encrypted device and/or on a memory file system. That will make sure that there ist no unencrypted stuff left behind after a power-failure or crash. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
I would prefer to have the plain text around after a power failure because it could be several days of work and as I said the only reason for all this is to make the client comfortable and not that I do not trust the team (I do trust them) On Sat, Sep 11, 2010 at 11:10 AM, Oliver Fromme wrote: > Aryeh Friedman wrote: > > In this case the admin and developer are the same person... namely at > > the clients request I am the only person allowed to work on the > > project and I just want to make it so I can't accidently do something > > like control-d or something like that and leave a plain text version > > of a project that has a very strict NDA laying around (liquidated > > damages of $250k)... the scenrio is we a are a team (each one of us is > > in diff city) of freelance CS people and all use the same server for > > all our development to make cooperation possible when needed (not in > > this case) have centralized backups, etc. and as mentioned on this one > > project the client has forced me to sign a NDA saying I can't even > > show the code to the other team members without the client's > > permission and thus am storing the repo using security/fuse-encfs, but > > since the version control system (devel/aegis) requires creating a > > development directory that is not encrypted I want to force/remind > > myself to checkin what ever I was working into the encrypted repo when > > I go "home" (it is a home office ;-)) at night or out to lunch > > If it's just a reminder to yourself, then I would simply > remove the keybinding for ^D (or bind it to something else; > the details depend on your login shell) and alias "exit" > and "logout" to a script that checks the working directory > of your version control system. If things have been checked > in correctly, it logs you out, otherwise it prints a message > and terminates, throwing you back to the shell prompt. > > Additionally, you could put the checked-out files on a > geli-encrypted device and/or on a memory file system. That > will make sure that there ist no unencrypted stuff left > behind after a power-failure or crash. > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- > chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "Python is an experiment in how much freedom programmers need. > Too much freedom and nobody can read another's code; too little > and expressiveness is endangered." > -- Guido van Rossum > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
On 9/11/2010 10:18 AM, Aryeh Friedman wrote: ys of work and as I said the only reason for all this is to make the client comfortable and not that I do not trust the team (I do trust them) Write a script that gets executed in the background once you log in that will periodically check to make sure you're still logged in and if not, commit and delete. If you have a power failure, the script won't be running until you log in(unlike using cron), and when you log in after a power failure it should still all be there. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
For reasons explained in an earlier reply this is a very *BAD* idea due to how devel/aegis is structured On Sat, Sep 11, 2010 at 12:32 PM, Joshua Isom wrote: > On 9/11/2010 10:18 AM, Aryeh Friedman wrote: >> >> ys of work and as I said the only reason >> for all this is to make the client comfortable and not that I do not >> trust the team (I do trust them) > > Write a script that gets executed in the background once you log in that > will periodically check to make sure you're still logged in and if not, > commit and delete. If you have a power failure, the script won't be running > until you log in(unlike using cron), and when you log in after a power > failure it should still all be there. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
Aryeh Friedman wrote: > I would prefer to have the plain text around after a power failure > because it could be several days of work ... Ideally there should be _some_ mechanism for committing unfinished work to a (probably encrypted) repository on, at least, a daily basis. The more I see of this thread, the more it seems that the problem is largely the fault of the particular VCS being used. A VCS that demands a "review" step before anything can be checked in, even on a "work in progress" branch as opposed to the mainline, seems a poor fit for a project in which developers are not permitted to see one anothers code. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
Since we have been using aegis for years and know it like the back of our hand I don't want to learn a new tool... but I think your right I am going to forward/cross post this entire thread to the aegis mailing list. On Sat, Sep 11, 2010 at 7:11 PM, wrote: > Aryeh Friedman wrote: > >> I would prefer to have the plain text around after a power failure >> because it could be several days of work ... > > Ideally there should be _some_ mechanism for committing unfinished > work to a (probably encrypted) repository on, at least, a daily > basis. > > The more I see of this thread, the more it seems that the problem > is largely the fault of the particular VCS being used. A VCS that > demands a "review" step before anything can be checked in, even on a > "work in progress" branch as opposed to the mainline, seems a poor > fit for a project in which developers are not permitted to see one > anothers code. > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
Atom Smasher wrote: On Fri, 10 Sep 2010, Ivan Voras wrote: 1) power outage of the server 2) power outage on the client 3) network problems (ssh or TCP connection drop) 4) administrative command (e.g. root executes "killall $shell") ? I don't think there is a way to protect from all of those, so any effort in protecting from only part of the problem looks useless. you forgot cosmic rays, nuclear war and zombie apocalypse, among other failure modes. *NOTHING* is capable of protecting against everything; a good solution will most always have pitfalls; as a sysadmin/engineer/manager one has to either accept the pitfalls or find a more acceptable solution, which usually means different pitfalls. that doesn't mean a given solution is useless. Bah. since you mentioned .logout, i'm assuming you are using tcsh. what i would suggest is that you create an md and check out the files into that. this solves the power fail issue completely, also, it solves the main issue. have the logout script simply umount and mdconfig -d the ramdisk. also, this way, security is enhanced because no fragments, even of deleted files, are left on disk after logout. the only question i have is if a bzero is done before returning the ram to the os, if not, simply dd if=/dev/zero of=/dev/md0 bs=whatever to be sure that the ram formeerly contained in the ramdisk isn't readable by later procs. have you considered trustedbsd? it should perform the bzero by default. TBSD MAC is in fbsd these days to control access to the mountpoint, but that might not help if you are worried about a lifted disk, MAC don't mean shit without physical security, the kind involved in the environments for which it was commissioned. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
